Internal and external object APIs (was: [Proxies] Refactoring prototype climbing in the spec)

David Bruant bruant.d at
Thu Nov 10 08:23:01 PST 2011

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
* Object.freeze(o)
* Object.seal(o)
* Object.preventExtensions(o)
* name in 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]



More information about the es-discuss mailing list