On Dec 28, 2012, at 11:19, "Andreas Rossberg" <rossberg at google.com<mailto:rossberg at google.com>> wrote:

On 28 December 2012 16:20, Domenic Denicola <domenic at domenicdenicola.com<mailto:domenic at domenicdenicola.com>> wrote:
Finally, I can't shake the feeling I'm missing something. Why is this aliasing property valuable, given that it's so contradictory to expectations?

Your expectations must be different than mine. :)

Dave and Sam may have a different answer, but I'd answer that the aliasing semantics follows from a module system's role as (among other things) a name spacing mechanism.

This idea of modules as namespaces is a very interesting one I hadn't considered. My experience is with C++/C# namespaces, and with ES5 modules. With only this experience, the two concepts seem worlds apart. Are there other precedents where something by the name of "modules" acts like C++/C# namespaces, e.g. Ruby or Python? If not, perhaps the feature should be renamed to avoid confusion?

I guess this point of view explains why there was so much TC39 interest in `import *`.

I think that the loss of either of these properties would make modules far more surprising, and refactoring code into modules harder and more error-prone.

To who, though? I'm hesitant to draw on existing ES5 module systems as precedent, given their major flaws with regard to static compilation (and the underlying priorities these flaws reveal). But if you're talking about refactoring existing code, and surprisingness to existing ES programmers, I think you have to consider module usage today.

You could argue that "most" ES programmers aren't using modules today, so preserving the intuitions of and making refactoring easier for that minority isn't valuable. You might be correct, but I think the most avid early adopters who will drive ES6 forward are precisely the ones using ES5 modules. Furthermore, many of those not using modules are using "namespaces" via global object hierarchies, which (without `with`) have no aliasing properties.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121228/52fd4201/attachment.html>

On Dec 28, 2012, at 11:19, "Andreas Rossberg" <rossberg at google.com<mailto:rossberg at google.com>> wrote:

> On 28 December 2012 16:20, Domenic Denicola <domenic at domenicdenicola.com<mailto:domenic at domenicdenicola.com>> wrote:
> > Finally, I can't shake the feeling I'm missing something. Why is this aliasing property valuable, given that it's so contradictory to expectations?

> Your expectations must be different than mine. :)

> Dave and Sam may have a different answer, but I'd answer that the aliasing semantics follows from a module system's role as (among other things) a name spacing mechanism.

This idea of modules as namespaces is a very interesting one I hadn't considered. My experience is with C++/C# namespaces, and with ES5 modules. With only this experience, the two concepts seem worlds apart. Are there other precedents where something by the name of "modules" acts like C++/C# namespaces, e.g. Ruby or Python? If not, perhaps the feature should be renamed to avoid confusion?

I guess this point of view explains why there was so much TC39 interest in `import *`.

> I think that the loss of either of these properties would make modules far more surprising, and refactoring code into modules harder and more error-prone.

To who, though? I'm hesitant to draw on existing ES5 module systems as precedent, given their major flaws with regard to static compilation (and the underlying priorities these flaws reveal). But if you're talking about refactoring existing code, and surprisingness to existing ES programmers, I think you have to consider module usage today.

You could argue that "most" ES programmers aren't using modules today, so preserving the intuitions of and making refactoring easier for that minority isn't valuable. You might be correct, but I think the most avid early adopters who will drive ES6 forward are precisely the ones using ES5 modules. Furthermore, many of those not using modules are using "namespaces" via global object hierarchies, which (without `with`) have no aliasing properties.