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

Brendan Eich brendan at
Mon Oct 1 16:55:30 PDT 2012

Allen Wirfs-Brock wrote:
> On Oct 1, 2012, at 3:48 PM, Brendan Eich wrote:
>> Allen Wirfs-Brock wrote:
>>> Let me try explaining this again,
>> No need to rehash.
>> Responding to my point about other legacy "tag tests" that are not 
>> twiddled with "~" and so are possibly "invalidated" would be helpful. 
>> *Why* are the core language names sacrosanct when tag-testing of 
>> other class names is also potentially just as important, e.g., for SES?
> My main concern isn't SES-like things.  It is random general use of 
> Obj.proto.toString to identify instances of built-ins such as Array 
> and Function.
> I think we have to support reliable Obj.proto.toString-based tag-test 
> for "Arguments",

I doubt any deployed JS code cares -- that's new in ES5. Prior to ES5, 
arguments objects seemed to be "Object" instances. People do not write 
ES5-only JS. Testing for arguments across pre-ES5 and ES5 engines is 
thus "hard" and not done in my experience.

> "Array", "Boolean", "Date", "Error", "Function", "JSON", "Math", 
> "Number", "RegExp", and "String" because those specific values are 
> explicitly defined in the ES5.1 specification and are universally 
> supported by implementations.

This is circular, though. The spec is not the interop or backward 
compatibility requirement, it's map not terrain!

The dangerous objects outside of these may well be of more real 
compatibility importance. Suspect Mark knows all but is filtering email.


More information about the es-discuss mailing list