On Mon, Jul 29, 2013 at 3:12 PM, Brendan Eich <[email protected]> wrote:
> ๏̯͡๏ 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<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<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. If the semantics are non-lexical, I don't think the save & restore technique could be easily adopted by a library unless the library did the save on entry to every function and a restore on exit. Take for example, if jQuery wanted to use a sensible typeof but a program using jQuery did not. You'd also have to maintain the option of opting in and out of sensible-typeof which unfortunately means we cannot adopt your suggestion of "opting and no going back" below. 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. > I was also thinking about a pragma but if they're deferred and not usable, how about instead of a flag that changes the semantics of the existing typeof, introducing the better typeof say on Function instead. Again it would mean legacy code and code that was uninterested in adopting a better typeof would continue to work unaffected. You've managed to successfully root out so many of the dynamic scoping modes (arguments.caller, with etc) that it feels worthwhile to try to avoid reintroducing one if we can avoid it. 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. *gack* Sorry - complete braino. > 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? I don't think we'd want to allow the switching of values for SES - it would be a small (single bit) implicit communication channel and more importantly an interference hazard from hostile code. If at initialization a SES module declared which typeof it wanted, that would be sufficient. This is of course equivalent to a lexical scope for the entire SES module. 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. > A bit behind on reading up the operator proposals - it's on my list! 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
