Le 10/11/2011 12:28, David Bruant a écrit :
(...)
but i think [traps] should be a right balance between the internal and
external API.
Internal object API:
* getPropertyDescriptor(propName)
* setPropertyDescriptor(propName, desc) (more or less equivalent to the
current [[DefineOwnProperty]])
* delete(name)
* getPropertyNames()
* makeNonExtensible()
* getPrototype()
* getDefaultValue(hint)
* getClass()
I would claim that anything done in the ES5.1 spec with objects
(functions aside for now) could be expressed as a combinaison of this
minimal internal object API. Some choices are intentional
(makeNonExtensible does not have a makeExtensible counterpart,
get{Prototype|Class} not having a "set" counterpart...).
Also, I do not write "getOwnPropertyNames", because as far as an
ECMAScript object is concerned, there is no reason to do something else
than adding an "own" property. Oh yes, there is this other object you
can have a reference to by calling "getPrototype", but there is no
reason to act on this one directly internally.
I'd like to emphasis that this minimal API defines objects as a mapping
of name -> property descriptors.
External object API:
** Current
* Object.getOwnPropertyDescriptor(o, name)
* Object.getOwnPropertyNames(o)
* Object.defineProperty(o, name, pd)
* delete o.name
* Object.freeze(o)
* Object.seal(o)
* Object.preventExtensions(o)
* name in o
* ({}).hasOwnProperty.call(o, name)
* o.name
* o.name = val
* for (name in o)
* Object.keys(o)
** Upcoming
* for(v of o)
* (I'm probably forgetting some)
Allen wrote:
More generally, I think there should be a 1::1 correspondence between
the internal methods in listed in ES5 Table 8 and fundamental proxy traps.
If by "fundamental", you were refering to something like the minimal
internal API I described above, once again, I disagree, but for
different reasons that before. First, I think that there is an agreement
to not trap some things like getPrototype, getClass or getDefaultValue.
Then, I think that if some traps (like "set" or "get") exist, it's
because it's a bit more convenient to reason on object interaction from
the syntax perspective than the "fundamental internal API". Actually,
proxies initial design rather makes a correspondance with syntax [1].
Regarding ES5 invariants, these were expressed in terms of internal API
opening the door to host object to do whatever they want in their
[[Get]] and [[Put]] internal methods. I'm glad to see invariants being
defined more closely to the syntax view of objects in the direct proxies
proposal [2]
David
[1] http://wiki.ecmascript.org/doku.php?id=harmony:proxies#api
[2]
http://wiki.ecmascript.org/doku.php?id=strawman:direct_proxies#invariant_enforcement
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
