domenic at domenicdenicola.com (2013-12-10T02:20:27.251Z)
On Sat, Dec 7, 2013 at 11:26 AM, Mark S. Miller <erights at google.com> wrote: > Without this > additional requirement, a non-extensible object can "hide" non-configurable > own properties from freeze, isFrozen, etc. Should be: ...can "hide" configurable own properties...
On Sat, Dec 7, 2013 at 11:26 AM, Mark S. Miller <erights at google.com> wrote: > On Sat, Dec 7, 2013 at 10:45 AM, Tom Van Cutsem <tomvc.be at gmail.com>wrote: > >> 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. >> > > Hi Tom, when we talked I think we overlooked something crucial. The > requirement as stated, "return at least the names (symbols or strings) of > all non-configurable properties", is not actually sufficient for freeze, > isFrozen, etc. We must additionally state that, if the object has been > observed to be non-extensible, then it may not afterwards claim to have any > own properties not observed by [[GetOwnPropertyNames]]. Without this > additional requirement, a non-extensible object can "hide" non-configurable > own properties from freeze, isFrozen, etc. > Should be: ...can "hide" configurable own properties... > > > >> [[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 <allen at wirfs-brock.com> >> >>> 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 >>> > es-discuss at mozilla.org >>> > https://mail.mozilla.org/listinfo/es-discuss >>> > >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131207/7295e616/attachment-0001.html>