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