Finiteness of object properties set

[Tom Van Cutsem]

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
of values.


> 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
> intuition.
>

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
issues.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110907/1bbd2ee4/attachment-0001.html>