On Jan 30, 2012, at 10:11 AM, Andreas Rossberg wrote:
> On 30 January 2012 18:16, Allen Wirfs-Brock <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
