On Oct 2, 2012, at 2:46 PM, Mark S. Miller wrote:
>
>
> On Tue, Oct 2, 2012 at 11:01 AM, Allen Wirfs-Brock <al...@wirfs-brock.com>
> 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.@FooBrand = true;
>> }
>> }
>> Foo.isFoo = function (obj) {return !!obj.@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 {
Map.prototype.size.call(obj)
} 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.
Allen_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
