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

Andreas Rossberg rossberg at google.com
Thu Jan 26 03:01:40 PST 2012


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.
:)  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.

> 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.

> 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.

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?

> 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