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

[Brendan Eich]

Mark S. Miller wrote:
> On Sat, Sep 29, 2012 at 10:21 PM, Mark S. Miller <erights at google.com 
> <mailto:erights at google.com>> wrote:
>
>
>     I agree that the only security issue is avoiding the
>     communications channel.
>
>     Security aside, given maximin
>
>         class Foo
>
>     what do you suggest Foo.prototype be?
>
>
> That was too vague. Reformulating.
>
> Private properties, i.e., properties named by symbols, are the class 
> analog to the internal properties of the built ins. The current 
> [[Class]] tests in ES5 are there essentially to ensure that these 
> internal properties exist and satisfy whatever invariant is assumed. 
> In maximin classes, we don't expand methods with an analog of that 
> [[Class]] check. Rather, the presence of these private symbol-named 
> properties implicitly provides the branding. Say class Foo uses symbol 
> @s to name a private instance property of instances of Foo, and that 
> method bar() of Foo accesses this @s property, failing if the object 
> doesn't have an @s. Clearly, bar() should fail on Foo.prototype just 
> as it should fail on any non-instance of Foo. This is already implied 
> by the mechanisms proposed for installing private instance variables.

Yup, and I dig it (Jason Orendorff many years ago suggested that Date 
should not have a [[Class]] check, rather simply use private-named 
properties which might even be inherited).

So is the only issue here that @@toStringTag is not set to "Foo", as 
Yusuke just suggested?

/be