array like objects

Brendan Eich brendan at
Tue Dec 15 20:28:13 PST 2009

On Dec 15, 2009, at 12:32 PM, David-Sarah Hopwood wrote:

> Exactly: [[Class]] is associated with each instance and so are the  
> other
> internal methods/properties, but that doesn't imply that other  
> properties
> are "defined based on" [[Class]].

The internal methods specified for built-in objects in the ES specs  
are not just happenstance. That they correlate with [[Class]] as if  
the latter were a nominal type id is no coincidence. You could say  
[[Class]] was "defined based on" the internal methods, but that is as  
backwards now as it was in the ES1 days when the spec was being  

The point remains that host objects and the native objects specified  
in Clause 15 act like nominal type instances. They do not delegate  
[[Put]] or other internal methods to any object, instead they call  
what is bound "in" the directly referenced instance. The idea of  
delegated [[Put]] is not done in ES specs, in fact it is ruled out.  
But delegating internal methods would allow composing array-ness via  
prototyping, as far as I can see. It would also allow, e.g., an Object  
instance to delegate to a Date prototype.

This is the road not taken, which opens the door for host object  
madness. It is true that even with delegated "internal" methods, i.e.  
no special nominal type-like binding of instances to "hooks", just  
private method names, one could make an inconsistent suite of the meta- 
methods for a given object kind. But there would be only one object  
system: prototype-based; instead of two: the hidden nominal type  
system underlying builtins and host objects, and the pure-JS prototype- 
based object world.

Something more like Self, in other words. I still wonder if we can't  
recover that lost form, enable prototype-based composition as Tucker  
wanted, and banish host objects to the ninth circle of hell, in a  
future edition.


More information about the es-discuss mailing list