On Sat, Dec 7, 2013 at 10:45 AM, Tom Van Cutsem <[email protected]> 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.
> [[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
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
