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

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Jan 30 10:44:27 PST 2012


On Jan 30, 2012, at 10:11 AM, Andreas Rossberg wrote:

> On 30 January 2012 18:16, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> Assuming this is a single Program or StatementList, the above is current
>> defined as being a static error.  The above would require changing decisions
>> that have already been made so I don't see why we should be considering such
>> cases unless we run into an issue that forces us to reconsider that
>> decision.
> 
> Yes, and just to be clear, I'm not at all advocating allowing it,
> quite the opposite.
> 
> 
>>> And as I said earlier, by allowing import shadowing, you could encode
>>> this, even if shadowing was disallowed for let itself.
>> 
>> I don't think so.  Imports are treated as local lexical bindings, just like
>> let and const so:
>> 
>> import {x} from wherever;
>> let x = 2;
>> 
>> is just as illegal as:
>> 
>> let x=1;
>> let x=2;
> 
> Sure, but I thought the case in question was
> 
> import x from wherever1;
> import x from wherever2;
> 
> (perhaps only in separate scripts). And my claim was that allowing
> this is just as problematic as a duplicate let.

separate scripts, and the same (or at least equivalent)  whatevers)

>>> ...
>> 
>> No, I suggesting allowing duplicate identical imports in separate
>> Programs while I would disallow (for STL) multiple lets for the same
>> identifier.
> 
> OK, I see. Then I somewhat misinterpreted what you wrote initially.
> But even with that in mind, I'm still slightly confused what exactly
> you were suggesting. In particular, did you assume that imports from
> one script are visible in later ones?

yes, that's what I mean by STL.  Binding are progressive added to the single top-level as each program is evaluated.


> 
> If not, then what environment do they go in? And why have different
> rules for imports and other bindings?
> 
> If they are, then you might still have the problem I was describing,
> if you want to allow duplicate imports as you suggested (what I call
> shadowing):
> 
> <script>
> import x from M1
> </script>
> 
> <script>
> function f() { return x }
> import x from M2
> function g() { return x }
> </script>
> 
> Which x does each function see, and why?

All lexical declarations within a StatementList (usually a Block, Function, or Module body) are logically hoisted to the top of the block where they are instantiated on entry.  There is only one x in the above script which both function see.  For bindings captured by functions, the placement of the function declaration within its statement list isn't particularly relevant. All that matters is that the captured binding is initialized by the time the function is actually called and reference the binding.

> 
> On the other hand, I see that in the OP you said "multiple equivalent
> imports", presumably ruling out examples like the above if both xs do
> not refer to the same thing. Was that the idea?

Yes, I was really trying to allow under STL for independent (and normally not inlined) scripts both containing things like:

// script 1
import $ from "someURL/jQuery";
....
 
//script 2
import $ from "someURL/jQuery";
...

If the imports were replaced by lets or const, STL would throw when instantiating the second script. 

Allen


More information about the es-discuss mailing list