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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
