tobie.langel at gmail.com
Thu Mar 12 21:16:05 PDT 2009
On Mar 13, 2009, at 03:13 , Brendan Eich wrote:
> Your proposal does not completely "fix" it, though, since the
> [[Class]] of Parent.prototype is "Object". It was not constructed by
> Parent. Maybe this is ok.
That actually didn't bother me that much (I was thinking in classical
rather than prototypal inheritance terms). Now that I've got my head
set straight again I do see how this is an issue.
It breaks the equality between the instance's and the prototype's
"[[Class]]" so that:
Object.getClassName(Parent.prototype) !== Object.getClassName(new
Turns out that there is a precedent (still in Firebug):
And yes, I know this is a host object.
> Outside of built-in classes, [[Class]] is used only for
> Object.prototype.toString. In TC39 we've argued about what [[Class]]
> means, and I've maintained it's a token corresponding in concrete
> implementation terms (vtable or equivalent) to a pile of code
> implementing a specific set of internal methods (like Array's custom
> So changing [[Class]] just to get a differnt
> Object.prototype.toString.call(obj) result is arguably wrong.
> Another option here is to add a different internal property,
That felt dirty. Now I know why.
> From the point of view of implementors, setting the "vtable" for an
> instance is not going to be done based on a string value in a
> property of F. In either case (step 2 or 3) the same implementation
> code for generic Object behavior, appropriate to [[Class]] "Object"
> in ES1-3, will be chosen.
Understood. Same issue as above.
> The only difference that matters (correct me if I'm wrong) is the
> output of Object.prototype.toString.call(obj).
That's correct. However your earlier comment about the broken equality
between the "[[Class]]" of Parent.prototype and a Parent "instance"
opened up my eyes. Is there a way around that ? Or is it a huge can of
>> There's probably a lot of issues I haven't foreseen here (on top of
>> the yet unspecified name property of functions), but it hopefully
>> helps to clarify what I was thinking about. It also avoids touching
>> the behaviour of the constructor property of the prototype object.
>> Given that spec change, I suspect Object.getClassName(o) could be
>> desugared to Object.prototype.toString.call(object).slice(8, -1).
> No, since outside of strict mode, Object is a writable, deletable
> property of the global object, and toString is writable/deletable in
> Object.prototype, and call can be shadowed, etc. etc.
Right. The fact that I wouldn't touch Object.prototype doesn't imply
someone else couldn't. :) And thank you for the precise definition of
More information about the Es-discuss