๏̯͡๏ Jasvir Nagra wrote:
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).
Hi Jasvir,
Tes: realm is the primordials (memoized internally at start of world;
older ECMA-262 specs wrote of "the original value of Array.prototype",
see latest draft at
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts and
search for "realm" for more).
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.
Right, so don't do that, or else dynamically save and restore for the
desired result. There's no assumption of hostile code here, as usual you
have to trust what you include into your single-frame/window (realm)
TCB, etc.
Similarly, the use of such a library in a program would suddenly
cause existing typeof conventions to break.
The intended use-case is where application top-level script changes
typeof null and proceeds with vetted library code.
In general, lexical scope is best. Could we have a pragma that changes
typeof null? We deferred real pragma syntax from ES6, perhaps from
Harmony (no more modes!), and "use null typeof sanity"; or whatever is
not enough, as it doesn't choke old browsers, so doubles the testing burden.
It is possible to write typeof-testing code that copes with either
"null" or "object" as the typeof null, as we've discussed in past TC39
meetings; this supports the idea of top-level dynamic opt-in with vetted
libraries.
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().
If you meanted typeof a; the second time, not typeof b; -- I agree, it
would. Almost as surprising as typeof null == "object" :-P.
Especially if you make typeof extensible, this kind of
action-at-a-distance will be a hazard to developers.
We could forbid switching back and forth between "null" and "object",
indeed. Then the repair is one-time, per-realm, but unlike with novel
value object types, code could witness two values for typeof null:
"object" and later "null". No going back to "object", however. Any
problems with that, from an SES point of view?
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.
Lexical scope wants new syntax delimited by the scope, which we could
certainly do. The value objects proposal so far has stuck with APIs, for
object detection and because operators rendezvous in the heap through
prototype lookup of @@ADD, @@ADD_R, etc. But their bindings to +, *,
etc. could indeed also be lexical -- we'd have scoped
operator-to-multimethod bindings, which may be overkill but could be
good for isolation and composition, as usual.
Syntax could be the way to go, though. But before I throw in the towel,
could you comment on one-time (const-like) typeof definition approach
for novel value objects? And of course the "object" => "null" dynamic
change for typeof null. Thanks,
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
