As currently specified, [[OwnPropertyKeys]] doesn't have any particular
invariants on the values it generates from the returned iterator.
Mark and I proposed to reintroduce [[GetOwnPropertyNames]] as a separate
internal method, which would return an array rather than an iterator, but
which would also be required to return at least the names (symbols or
strings) of all non-configurable properties. The switch to an array return
value is motivated partly by the reasons Jason stated, but also because
actually checking the invariant requires exhausting the iterator anyway.
[[OwnPropertyKeys]] would continue to return an iterator (or iterable , as
Jason suggests, which seems to make more sense), but there would be no
invariants on its generated values.
[[GetOwnPropertyNames]] would be the reliable way of querying an object for
its own properties, and would be used at least by
Object.getOwnPropertyNames and the abstract operations used by
Object.{freeze,isFrozen,seal,isSealed}, so that the result of these
operations can in turn be made reliable.
[[OwnPropertyKeys]] can be used for all other operations that don't need
the invariant that all non-configurable properties should be
listed/generated.
Cheers,
Tom
2013/12/6 Allen Wirfs-Brock <[email protected]>
> I'm working with TomVC right now on revising these internal methods. More
> on that soon.
>
> One possible advantage of using an Iterator is that large dense indexable
> objects such as typed arrays, strings, or similar abstractions defined
> using a proxy don't have to instantiate an
> Array containing huge numbers of element indices.
>
> Also we have talk about, the future addition of user land iterator valued
> functions such as keys, ownKeys, etc. or the possibility of frameworks
> providing such functions. The internal methods. The MOP defined by the
> internal methods should provide a stable foundation for such future
> extensions.
>
> Allen
>
>
> On Dec 6, 2013, at 6:35 AM, Jason Orendorff wrote:
>
> > It looks like [[OwnPropertyKeys]] is defined to return an iterator.
> > But the ordinary [[OwnPropertyKeys]] method produces the List of keys
> > to be iterated eagerly, and pretty every place that calls the method
> > immediately consumes the entire iterator. So there is no actual
> > laziness.
> >
> > This is weird. I think it would be clearer for [[OwnPropertyKeys]] to
> > return a List of PropertyKeys.
> >
> > Except for proxies, this doesn't change behavior. Here are the changes
> > needed to implement this:
> >
> > * In 9.1.12, the ordinary object [[OwnPropertyKeys]] method, change
> > step 3 to just say "Return keys." instead of "Return
> > CreateListIterator(keys)."
> >
> > * In 9.5.12, the Proxy [[OwnPropertyKeys]] method, treat the return
> > value as an iterable (not an iterator) and convert it to a List of
> > PropertyKeys using IteratorStep, IteratorValue, and ToPropertyKey.
> > Change the NOTE to describe the new invariant.
> >
> > * In 19.1.2.1 Object.assign, 19.1.2.8.1 GetOwnPropertyKeys, 19.1.2.14
> > Object.keys, and 19.1.2.15.1 MixinProperties, drop the IteratorStep
> > boilerplate.
> >
> > * In 26.1.10 Reflect.ownKeys(), convert the result of calling
> > [[OwnPropertyKeys]] to an Array using CreateArrayFromList.
> >
> > Note that 7.3.10 SetIntegrityLevel and 7.3.11 TestIntegrityLevel
> > already assume that [[OwnPropertyKeys]] returns a List, as proposed.
> >
> > -j
> > _______________________________________________
> > es-discuss mailing list
> > [email protected]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
