The global object should not be the "global scope instance object"

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Jan 26 08:47:33 PST 2012


On Jan 26, 2012, at 3:01 AM, Andreas Rossberg wrote:

> On 26 January 2012 01:11, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> The following proposal questions the validity of the teeshirt maxim "Let is
>> the new var" as a rationale for treating global |let| declarations similarly
>> to ES<=5 global |var| declarations. While we want people to use |let| (and
>> |const|) in preference to |var| we don't want to unnecessarily perpetuate
>> undesirable aspects of the current browser ES global environment  that
>> aren't strictly needed to maintain compatibility with existing code.
> 
> I'm happy to see a move towards a more declarative toplevel
> environment. I think we are on the same page there, and there is no
> real difference in that respect between what you propose and what I
> suggested earlier.
> 
> If I understand things correctly, then the main observable difference
> to my proposal is that let/const bindings should not be reflected on
> the global object at all (and instead, can actually shadow preexisting
> properties). I was under the impression that people would demand lets
> to show up, so my main intent was to suggest a safe solution that does
> not compromise declarative semantics. But if there is consensus on
> making a more radical break, then I'd be the last to argue against it.
> :)  

There certainly wasn't consensus about this at last week's meeting.  But there also isn't any web compatibility requirement for binding let's in the global object.  I'm hoping the proponents of doing so will reconsider their position. 

> The ability to shadow pre-existing bindings, and thus avoid scope
> pollution problems, is a good motivation, and implemented cleaner
> based on nested environments than on prototype chains.
> 
> A couple of questions/comments:
> 
>> var foo() {};
> 
> I haven't seen this syntax being proposed for var before.

typo, I meant function

> 
>> When evaluating a Program all |let| and |const| declarations at the top
>> level of the program attempt to create  bindings in the top-level
>> environment. Bindings imported  at the top level from modules are treated
>> similarly to |let| or |const| bindings (as appropriate) except that multiple
>> equivalent imports are allowed .
> 
> Overlapping imports? That's the first time I hear about that. That
> might be rather difficult, given that modules are recursive.

It's just something I threw in that the module champions need to weigh in on.  It seems desirable to allow things like:

<script>
import {create} from "@names";
const foo = create();
</script>
<script>
import {create} from "@names";
const bar = create();
</script>

(and, of course, the scripts would most likely be independent files).
I don't see why circularities involving the imported module would create any problems in this situation.  It probably helps that we are talking about top level scripts that aren't themselves modules.



> 
>> In the above I haven't addressed which environment is used to bind the ES
>> built-in globals.  I'm assuming, that for compatibility reasons, these need
>> to continue to be bound in the host environment (ie, properties of the
>> global object).  I would prefer to place them in a separate enviornment
>> record.
> 
> I share the sentiment, but wouldn't that imply that the built-ins no
> longer show up on the window object? That seems to be a breaking
> change.

Yes, assuming that people do things like:
   new window.Array();

That's why I said that I doubted its plausibility.

> 
> I also wonder how this idea would interact with module loaders, where
> you can define custom global environments. Would there be a way to
> customize both environments?

I assume that a module loader could set up an environment exactly like this (assuming we give them the right primitives for constructing environments)

> 
>> If that was plausible (which I doubt) I would have to give further
>> thought to whether the environment for built-ins would be between the host
>> environment and the top-level environment (ie shadowing the host environment
>> and shadowed by the top-level) or shadowed by the host environment.
> 
> The former seems far more desirable, as it makes sure that you cannot
> accidentally shadow the built-ins by random HTML stuff.
> 
> /Andreas
> 



More information about the es-discuss mailing list