New ES6 draft now available

Brendan Eich brendan at mozilla.org
Sat Nov 24 16:32:26 PST 2012


David Bruant wrote:
> Hi,
>
> I haven't been following very closely some of the most recent 
> discussions, so I appologize if my comments have been addressed already
>
> Le 23/11/2012 18:48, Allen Wirfs-Brock a écrit :
>> Changes include:
>>
>> • Reorganized Chapter 8 into separate language type and specification 
>> type sub sections
>> • Added Symbol property keys to the definition of the Object Type. 
>> terminology migration from talking about “property names” to 
>> “property keys”.
> I support this change. It's somewhat minor, but clearly indicates that 
> a shift has occured.

+1

>> • MOP changes: Added [[GetInheritance]]/[[SetInheritance]] as 
>> internal methods for accessing [[Prototype]] internal prototype chain.
> Why not [[GetPrototype]] and [[SetPrototype]]? We have a absurd number 
> of excellent resources (including but not limited to Dmitry Soshnikov 
> and Axel Rauschmayer's websites/blogs) which use extensively the ES5 
> internal [[Prototype]]. It's also been very hard to get people to 
> understand the difference between .prototype and [[Prototype]]. I'm 
> afraid a new change would create a lot of confusion.

Yes, please -- let's not change names gratuitously. [[Prototype]] stays, 
so these should be related names.

>> Added [[[IsExtensible]]/[[PreventExtensions]].
> ES5 had a note mentioning that there was no standard mechanism to set 
> [[Extensible]] from false to true; this new way makes the note 
> unnecessary by design of having internal methods instead of an 
> internal property. OCaps FTW I guess :-)

Or just a restrictive MOP FTW ;-).

>> Replaced [[Get]]/[[Put]] with [[GetP]]/[[SetP]]. At some point we may 
>> be able to rename these as [[Get]]/[[Set]].
> +1 for [[Get]]/[[Set]]. That's the accessor terminology, that's what 
> JS devs are used to. It makes the spec easier to read for them.

Yes, I assumed the -P suffixing was a temporary renaming aid. Allen, can 
you confirm?

>> Eliminated [[GetProperty]], [[CanPut]], [[HasProperty]], 
>> [[DefaultValue]].
> So good to see this cleanup :-)

+10!

> 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.

>> • instanceof operator no longer uses an internal method. Instead, 
>> extensible via a @@hasInstance symbol-keyed regular method.
> I don't remember a discussion on this topic, but I think it's an 
> interesting change. Is it for browser APIs?

Yes, the DOM specifically, and WebIDL in general.

> There might be an associated security worry here if any object can 
> have its @@hasInstance changed, but one good thing is that the debate 
> of trapping instanceof ends if it's a symbol-keyed method.

Proxies have trap integrity, that is, you can't mess with their handlers 
to mutate traps unless you are granted the handler capability. Right?

>> • Defined all of the functions in the @Reflect module corresponding 
>> to MOP internal operations.
> IIRC __proto__ has been agreed to be an data property

The jury is still out (could be accessor with poisoned reflection), but 
this is not material to your point.

> 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.

/be


More information about the es-discuss mailing list