New ES6 draft now available

Tom Van Cutsem tomvc.be at gmail.com
Sun Nov 25 12:53:09 PST 2012


2012/11/25 Brendan Eich <brendan at mozilla.org>

> David Bruant wrote:
>
>> Here is an idea to uniformize the enumeration story while removing
>> enumeration inconsistency footgun. I'll describe it in proxy trap terms. A
>> unique trap (or internal operation)
>
>  keyEnumerate: () -> iterator for {propertyKey, enumerable}
>> There is this unique operation which returns an iterator not for property
>> keys, but for an object containing a property key and a boolean signifying
>> the enumerable boolean.
>> Using this, each userland operation would use this iterator, drain it out
>> (unless the iteration is being aborted like by throwing in a for-in loop)
>> and filter out based on the exact userland operation so that:
>> * All would filter out if propertyKey is ever a private symbol
>> * Object.getOwnPropertyNames would keep all other property keys
>> regardless of the enumerable value
>> * Object.keys would filter out properties which are described as
>> non-enumerable
>> * for-in would filter out non-enumerable and retrieve the different
>> keyEnumerate from the prototype chain objects.
>> With this unique internal operation, an object is able to communicate its
>> intent regarding what's enumerated and each enumeration userland operation
>> only keeps what it's interested in.
>>
>
> As an internal method architecture for the spec, this seems fine -- the
> "object" returned cannot be observed and could be an internal type, a la
> Reference.
>
> For a proxy trap, this seems too low-level and the overhead (without
> optimization to look into the continuation for a destructuring pattern and
> avoid the object allocation) is again a potential problem. Tom should weigh
> in.


I'm not too worried about inconsistencies between traps. I don't see it as
sufficient reason to refactor the current
getOwnPropertyNames/keys/enumerate trap design.

Of course I'm open to alternatives if people think it is a major issue.


> and there was no Reflect.setPrototypeOf operation in the harmony Reflect
>> module proposal on purpose so that 'delete Object.prototype.__proto__' at
>> any point would be enough to be sure that all [[Prototype]]-setting
>> capabilities are removed.
>> So I think the Reflect.setPrototypeOf should be removed.
>>
>
> Yes, we covered this on-list extensively. There should be no
> *.setPrototypeOf function anywhere.


I agree. I don't think we want Reflect.setPrototypeOf.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121125/37417d31/attachment-0001.html>


More information about the es-discuss mailing list