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
built-ins.
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 {...}
and
C.prototype instanceof Object
when the cowpath today wants
C.prototype instanceof B
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
