Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)
brendan at mozilla.org
Sat Sep 29 23:11:14 PDT 2012
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?
More information about the es-discuss