New ES6 draft now available

David Bruant bruant.d at gmail.com
Sat Nov 24 05:31:59 PST 2012


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.

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

> 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 :-)

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

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

> Added Keys, [[OwnPropertyKeys]], [[Freeze]], [[Seal]], [[IsFrozen]], 
> [[IsSealed]].
For both the enumerations and the layer on top of [[PreventExtension]], 
I'm uneasy.
* [[Enumerate]], [[Keys]] and [[OwnPropertyKeys]] are very close operations
* So are [[PreventExtensions]]/[[Freeze]]/[[Seal]] on one side and 
[[IsExtensible]]/[[IsFrozen]]/[[IsSealed]]

I'm afraid that making them distinct operations increases footgun-ness. 
[[HasProperty]] has been removed in favored of [[HasOwnProperty]] (which 
might be removed in favor of only keeping [[GetOwnProperty]], though the 
conclusion of the discussion was the keep both IIRC) because the former 
could be "robustly" composed between

For proxies, [[Extensible]]ity-related operations have invariants so 
inconsistencies between [[PreventExtensions]], [[Freeze]], [[Seal]], 
[[IsExtensible]], [[IsFrozen]] and [[IsSealed]] are impossible.
However, one can legitimately wonder what will happen if a new built-in 
operation using [[PreventExtensions]] is introduced in a later version 
of ECMAScript. Let's say experience with unique/private symbols reveals 
that the current Object.freeze behavior (whatever it is in regard to 
symbols) is inappropriate and that adding a new 
Object.freezeWithDifferentSymbolHandling is introduced. The current 
pattern suggests that adding new 
[[FreezeWithDifferentSymbolHandling]]/[[IsFrozenWithDifferentSymbolHandling]] 
internals will be the way to go.
I'm not sure it's a good pattern.


The issue seems worse in footgunness scale for enumeration operations 
because different operations could yield completely unrelated results. 
And once again, if it is wanted to add a new enumeration operation on 
syntax surface, it seems that a new internal operation will be necessary.

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.


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

> . Defined all of the functions in the @Reflect module corresponding to 
> MOP internal operations.
IIRC __proto__ has been agreed to be an data property 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.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121124/2c49f063/attachment.html>


More information about the es-discuss mailing list