I am not sure I completely understand what a realm is but I am assuming it
is similar to a set of primodials (say an iframe in a browser).

Unless I am really misreading your examples, I do not think the new
proposal overcomes the problems of http://wiki.ecmascript.org/**
doku.php?id=harmony:typeof_**null<http://wiki.ecmascript.org/doku.php?id=harmony:typeof_null>.
If Function.setTypeOf dynamically affects subsequent use of typeof, then
action-at-a-distance problems will persist.  If one library adopts one
convention regarding typeof null and another a different one, then these
libraries will not be useable together.  Similarly, the use of such a
library in a program would suddenly cause existing typeof conventions to
break.  Finally, given the following snippet:

var x = typeof a;
f();
var y = typeof b;

it would be surprising to me if x !== y just because f() happened to call
Function.setTypeOf().

Especially if you make typeof extensible, this kind of action-at-a-distance
will be a hazard to developers.

If we must make typeof extensible, it would be less of a hazard if the
effect of the declaration was lexically scoped.  In that case, it
would genuinely affect only new code and maintain the invariants of legacy
code.

Jasvir Nagra


On Sun, Jul 28, 2013 at 11:57 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Axel Rauschmayer wrote:
>
>> Again, are you suggesting a retrofit along the lines I diagrammed, so
>>> that ("hi" instanceof string) would be true?
>>>
>>
>> I don’t have a definite answer for how to best fix this, but it would be
>> lovely if we could.
>>
>
> Would it? Having string as well as String might be useful at the limit,
> but is string.prototype the same object as String.prototype, or an Object
> instance full of the same methods?
>
>
>  I find it challenging myself ATM and pity newcomers.
>>
>
> Are newcomers going to face string and String? If yes, that seems worse
> than status quo. If no, then you're hiding string from them, not String,
> and recommending typeof to distinguish string from other values -- so how
> is that different from status quo?
>
> It seems to me the issue is not newcomers or whether instanceof can be
> made to supplant typeof (cross-frame issues remain but they vex any
> extensible mechanism too, as I conceded in the earlier posts talking about
> realms). The issue is whether we want a bunch of "constructors" (not
> callable via 'new', remember) in a tree that spans some kind of subtype
> semi-lattice -- but which may not pay for its user-facing-complexity costs.
>
>
>  So I’m insisting more on the problem than on my solution.
>>
>
> There are trade-offs but I don't see a clean win. Going back to 1995 and
> making "everything an object" (and no typeof at all? cross-window was a
> thing then too) is a dream. We should stick to realistic alternatives and
> weigh them carefully.
>
>
> /be
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130729/7e37e3c9/attachment.html>

I am not sure I completely understand what a realm is but I am assuming it
is similar to a set of primodials (say an iframe in a browser).

Unless I am really misreading your examples, I do not think the new
proposal overcomes the problems of http://wiki.ecmascript.org/doku.php?id=harmony:typeof_null.

If Function.setTypeOf dynamically affects subsequent use of typeof, then
action-at-a-distance problems will persist.  If one library adopts one
convention regarding typeof null and another a different one, then these
libraries will not be useable together.  Similarly, the use of such a
library in a program would suddenly cause existing typeof conventions to
break.  Finally, given the following snippet:

```js
var x = typeof a;
f();
var y = typeof b;
```

it would be surprising to me if x !== y just because f() happened to call
Function.setTypeOf().

Especially if you make typeof extensible, this kind of action-at-a-distance
will be a hazard to developers.

If we must make typeof extensible, it would be less of a hazard if the
effect of the declaration was lexically scoped.  In that case, it
would genuinely affect only new code and maintain the invariants of legacy
code.