[[OwnPropertyKeys]] key ordering
Mark S. Miller
erights at google.com
Tue Apr 22 11:03:54 PDT 2014
I would prefer that this implementation limit be treated even more like the
stack limit; say by throwing an error rather than silently adding a 1+2^24
property that breaks the contract. Any reason not to throw an error on this?
That said, I agree that this should be an implementation limit rather than
relaxing the contract. As an implementation limit, it is **currently** none
of the spec's business how an implementation handles it. However, sound
reasoning about security is impossible so long as such behavior in not
specced. We'll get around to speccing constraints on how implementations
may go wrong when they exceed this limit when we do for other limits, such
as stack depth. For example, although stack depth limits are outside the
spec, we'd all consider it wrong for an implementation to lose memory
safety when this limit is exceeded. Eventually, likewise for some other
limits and some other invariants.
On Tue, Apr 22, 2014 at 10:26 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com>wrote:
> On Apr 22, 2014, at 8:45 AM, Andreas Rossberg wrote:
> > On 22 April 2014 16:52, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> >> On Apr 22, 2014, at 12:02 AM, Andreas Rossberg wrote:
> >>> On 19 April 2014 20:14, Allen Wirfs-Brock <allen at wirfs-brock.com>
> >>>> The ordering I propose is:
> >>>> 1) All array index property keys, in ascending array index numeric
> order. Followed by:
> >>>> 2) All other string property keys, in property creation order.
> Followed by:
> >>>> 3) All symbol property keys, in property creation order
> >>> Creation order? I don't know about other VM's, but for V8 it's
> >>> unlikely that we are willing to pay the price for tracking that
> >>> accurately.
> >> My recollection of the last time we surveyed this was that all major
> engines did for-in enumeration of non-array index own property keys in
> creations/insertion order. Has something changed for V8 in this regard?
> My understanding is that the web depends upon that ordering for such
> > We do track it for up to 2^24 properties, after that we give up. As
> > far as the web is concerned, that is more than enough (and you most
> > likely run OOM before that anyway). A specialised test might try to
> > push it, though. I suppose you could argue that is simply an
> > implementation limit, like stack limits.
> I think treating this as an implementation limitation is just fine. I'd
> prefer not to explicitly state such a permision in the spec. (just like we
> don't for stack depth) because I wouldn't want to come up with an specific
> number and I wouldn't want any implementation to interpret the lack of a
> specific number as permission to set a silly limit like 8.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss