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.

Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to