Brendan Eich (2013-07-29T22:12:41.000Z)
domenic at domenicdenicola.com (2013-08-12T05:21:01.876Z)
๏̯͡๏ 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). 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: > > ```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(). 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.