Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

Allen Wirfs-Brock allen at
Tue Oct 2 08:55:48 PDT 2012

On Oct 1, 2012, at 9:56 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> We can try to tell ES implementors that they must do certain things in order to be in conformance but that really doesn't work for code written by users of the language.
> You're right, we'd be letting usercode, not just some (benign or malign, but if malign then game over already) host object, spoof a core language built-in.
> But if we have a solid branding mechanism (like Domado's ideal in latest browsers? ;-) then that should be used universally and this becomes a don't-care.
> /be

Great, but this is really an orthogonal issue from my extensible Obj.proto.toString design.

I did not intent that to be a branding mechanism.  Using toString for branding of builtins is a crock that was enabled by the ES spec leaking one of its internal abstractions.  toString's real role in life is just as a debugging aid that allows any object to present a string rendering of itself.  My primary goal with Obj.proto.toString was to make that debugging aid more easily extensible as make it easier for developer to define new object abstractions (classes) that are reasonable identified in their Obj.proto.toString renderings.

The only place that branding enters into this is in recognizing that existing working code uses Obj.proto.toString as a brand test for ES builtins.  The "~" spoofing prevention is only there to ensure that such code isn't broken. 

A new branding mechanism may be a fine thing to have (more on that in another reply) and if we have one it should be universally applied.  But that doesn't really have anything to do with toString as an extensible way to get a string object description or with the need to support legacy use of toString as a brand check on ES<=5.1 builtins.


More information about the es-discuss mailing list