Finiteness of object properties set

Tom Van Cutsem at
Wed Sep 7 06:12:04 PDT 2011

2011/9/7 David Bruant <david.bruant at>

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list