Read access to [[Class]]?

Brendan Eich brendan at
Sat Jan 28 20:16:13 PST 2012

John-David Dalton wrote:
>> Doing this naively will both impose unacceptable overhead*and*  allow
>> >  type-confusion attacks.
> I'm talking about adding back the wording that ES5.x currently has
> allowing host objects to set their own internal [[Class]] (or whatever
> it's new incarnation is) value. Most objects will still have an
> internal [[NativeBrand]] property of some kind associated with them so
> I don't see how this is an overhead concern.

It's not a problem if [[NativeBrand]] cannot be shadowed or own- vs. 
in-tested. Then it's just like [[Class]], only narrower.

>> >  Not at the price of per-instance "class-name".
> The current ES6 draft handles this by allowing objects to*not*  have a
> [[NativeBrand]] property

This too may be ok if not observable. But you wrote:

You could simplify it by making `NativeArray = "Array"` and
`NativeRegExp = "RegExp"` and so on. Then you could drop the "Tags"
table and extending the range of Object#toString is as easy as adding
a custom [[NativeBrand]] property value.

and Allen then replied:

But then, how would you implement it in pure ES code?

That's desirable for a self-hosted DOM, but the use of a private name 
means that we have two cases: private name not "in" the object, so use 
an internal "class test" equivalent in observable outcome via 
O.p.toString to ES1-5; private name "in" the object, use its value 

I don't see how to simplify further without using the private name for 
both cases, in which case we have overhead (less for "in" than "own", we 
could bind the private name in the appropriate prototype object) and, 
more significant: the type-confusion problem due to shadowing.


More information about the es-discuss mailing list