Object.prototype.inspect ?

Tobie Langel 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):

 >>> Object.prototype.toString.call(document.createElement('div'))
"[object HTMLDivElement]"
 >>> Object.prototype.toString.call(HTMLDivElement.prototype)
"[object XPC_WN_ModsAllowed_NoCall_Proto_JSClass]"

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  
> [[Put]]).
> 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,  
> [[ClassName]].

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  
worms ?

>> 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 mailing list