Finiteness of object properties set
Tom Van Cutsem
tomvc.be at gmail.com
Wed Sep 7 06:12:04 PDT 2011
2011/9/7 David Bruant <david.bruant at labri.fr>
> Le 06/09/2011 17:59, Mark S. Miller a écrit :
> I agree that the spec should clearly state that a non-extensible object
>> has a finite collection of own properties. Regarding infinite extensible
>> objects, the only problem I see off the top of my head is: What would
>> Object.getOwnPropertyNames return?
> And what about for-in loops? :-p
It's always possible to break/return early, no? Didn't iterators/generators
already cross this bridge? An iterator could iterate over an infinite stream
> If this is really considered, the problem to solve is to express an
> infinite set with a finite representation. RegExps may be a solution. One
> big question is on RegExp expressivity: Can any infinite string set be
> expressed with (a finite number of) JS RegExps? I have to admit that i know
> ECMAScript pretty well expect RegExp i have never taken the time to
> investigate, so i have no idea of the answer to this question, not even an
I have no idea where you are taking this, but trying to map infinite sets of
properties onto regular expressions seems like a horrible thing to do :-)
> Alternatively, extensible objects could be stated as having a finite set of
> properties. I have no knowledge of host objects with an infinite property
> set and everyone's intuition falls under the idea that objects are a finite
> collection of properties.
> Saying it explicitely would prevent attempts from ES implementors to have
> host objects with infinite property set. It would also allow to continue
> proxies with the current design tracks (which currently prevent infinite
> property sets).
I see no problem with current proxies emulating an extensible object with an
infinite set of properties.
Object.getOwnPropertyNames could return , claiming that all of these
properties were inherited. Even with invariant enforcement, the FixedHandler
does not enforce that getOwnPropertyNames returns all non-configurable own
properties observed thus far.
If these virtual properties are all marked non-enumerable, the "enumerate"
and "keys" trap can return  without lying.
Regarding invariant enforcement: if the generated properties are marked
non-configurable, the FixedHandler would require an unbounded amount of
storage, so that's something to consider.
But so as long as we're sticking to emulating an infinite series of
non-configurable properties on extensible objects, I see no show-stopping
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss