From: "David Herman" <dher...@mozilla.com>
> On Dec 31, 2011, at 6:08 PM, Oliver Hunt wrote:
> 
> >> # What about eliminating the window from the scope chain?
> >> 
> >> Short answer: giving up.
> > 
> > I think we can drop the global object from the scope chain in ES.  In the 
> > context of the browser we need to come up with a way to trigger it.
> 
> Maybe. I don't think it's as important. You can choose to use no globals 
> whatsoever if you want once we have the stdlib available via standard "@" 
> URL's.

Nit-fun: MRLs -- @ cannot begin a URL ;-). We're supposed to say URI (TBL and 
others pronounce it like "Yuri"), so maybe MRI. Magnetic Resonance Imaging...


> If we can find a simple way to opt out of the global object that isn't a 
> burden, I'm for it. But I suspect if it's too much work, it's just easier... 
> to not use the global object. :)

Right. But I doubt we'll find a simple enough way to opt out of the global 
object that's also compatible enough to migrate existing code into. That 
migration hazard, the first finger of fate when we said we intended to remove 
the global object as top scope, is huge. Lots of code on the web detects 
properties of window or |this| at top level while also declaring the same name 
via an uninitialized 'var'.


> > Someone brought up the typeof semantic change as concern :-/
> 
> I'm not concerned. It's technically doable, in that the change would only be 
> within module code. But I think changing the semantics of typeof in only part 
> of JS is a bad idea anyway. It's not enough win to pay for itself. And I 
> think it's pretty clear we can't change it everywhere without breaking the 
> web.

One counter-argument:

1. We want sane isObject and isNull predicates, ideally using typeof. Lack of 
them continues to bite people, as the web contains code that wrongly assumes 
typeof x == "object" => x.foo won't throw on null x.

2. We want typeof to improve when/if value types appear, and already IE extends 
typeof's result set, so people have to be careful not to write exhaustive 
typeof case analysis code.

3. Therefore, to make JS in the future (down the road and around the bend far 
enough that we can't see all the way -- and if we get there, the look back 
won't see bad old typeof null == "object") saner in its typeof semantics, we 
ought to bend a finger of fate on the runtime incompatibility of typeof null == 
"null".

I'm not going to die on this hill but I think it's worth a bit more thought, at 
least till midnight ;-).

/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to