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

Brendan Eich brendan at
Mon Oct 1 12:21:40 PDT 2012

Andreas Rossberg wrote:
> Er, from my reading that's clearly not what the Wiki says for WeakMap. 
> And it also is not what V8 implements, for either WeakMap or Map. 

Sorry, I was relying on Rick's testimony that the answers were 1) yes, 
2) no.

> V8 says no to both. And I fail to see what benefit there is to
> separating the two. In fact, it seems hostile to programmers to do so.

Either way, something splits. 1/2 = y/n requires a degenerate prototype 
of same class. 1/2 = n/n requires a split from all the ES5 and prior 

> I think Allen is absolutely right that the magic incest of current
> built-ins is not going to scale, is semantically questionable, and
> should best be abandoned.

Could you say a bit more?

There's a scaling problem indeed if each new class must enforce the 
degenerate prototype case with extra code. Using an Object instance to 
hold methods is a fixed extra cost (the "split from all the ES5 and 
prior built-ins" cost). Granted, implementations will have to do some 
work for the new classes that might hold mutable state. But they can 
systematize internally so this is not a new custom work each time a 
class with mutable state is added.

The best reason for using Object is the one Mark raised: class (as sugar 
for constructor/prototype) uses Object.

But if you've read the thread this far, my objective is not to enforce 
one implementation approach or the other. It's to use @@toStringTag and 
anything like it so there's no observable difference between the two 
approaches. Classes should be able to do likewise.

Otherwise we have

   class C extends B {...}


   C.prototype instanceof Object

when the cowpath today wants

   C.prototype instanceof B


More information about the es-discuss mailing list