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