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

Allen Wirfs-Brock allen at
Tue Oct 2 15:11:35 PDT 2012

On Oct 2, 2012, at 2:46 PM, Mark S. Miller wrote:

> On Tue, Oct 2, 2012 at 11:01 AM, Allen Wirfs-Brock <allen at> wrote:
> On Oct 2, 2012, at 10:18 AM, Kevin Smith wrote:
>> private @FooBrand;
>> class Foo {
>>    constructor() {
>>         /* establish the internal Fooness of the instance */
>>         this. at FooBrand = true;
>>    }
>> }
>> Foo.isFoo = function (obj) {return !!obj. at FooBrand};
>> Using this strategy, will isFoo not fail, if the specified object came from a different global context (frame)?
>> Kevin
> Indeed it would, but why shouldn't it?  Foo in another  frame is a different class.  If you need to do cross-frame brand, that seems like an additional requirement would require additional mechanism.
> Wouldn't a WeakMap branding scheme has similar issues. You would need to share via some means a common WeakMap among constructors in different frames.  Just like to make symbol based branding work for this requirement you would have to share a private symbol between frames.
> For classes, I agree it should fail cross frame -- they are different classes. But what about builtins? Note that ES5 [[Class]] is a cross-frame brand for builtins. And Array.isArray is an ad-hoc one-off cross-frame brand check.

If you take a look at the recent draft spec. for Map you will see that is uses an internal branding check that is supposed to work across frame.   If that check is properly implemented then one can code 

function isBuiltinMap(obj) {
   try {
   } catch (e) {return false};
   return true;

But this does raise an interesting question for self-host built-in and for any user self hosted class definitions.

The spec leaves it up to the Map implementation to define the mechanism for testing for the presence of [[MapData]]. But, in an ES self hosted implementation a private symbol or WeakMap registry  are probably the two most plausible available mechanisms.   Both of these would require some secure mechanism for cross frame sharing in order make the branding work cross frame.  I don't think we currently have this.  Perhaps it is a module loader issue.  Or perhaps it is an implementation issue.  If built-ins have magic powers and the implementation wants to support self hosting of built-in then perhaps it's the implementation responsibility to provide the mechanism for granting those powers. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list