ES Modules: suggestions for improvement

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Wed Jun 27 11:00:08 PDT 2012


On Wed, Jun 27, 2012 at 8:43 PM, David Herman <dherman at mozilla.com> wrote:

> On Jun 27, 2012, at 10:32 AM, Isaac Schlueter wrote:
>
> On Wed, Jun 27, 2012 at 9:39 AM, Brendan Eich <brendan at mozilla.org> wrote:
>
> var foo = 42;
>
> ... foop ...
>
>
> throws at runtime in ES1-5 if evaluation reaches the foop use, and (if you
>
> wrap a module around that hunk of code, and there's no global foop
> property)
>
> at compile-time (EarlyError) in ES6.
>
>
> I don't think that's a real problem.  Can you point to in-the-wild
> bugs caused by this?  Maybe it's a failure of imagination on my part.
>
>
> Well, this was a relatively high-profile example:
>
>     http://blog.safeshepherd.com/23/how-one-missing-var-ruined-our-launch/
>

I don't see how that's at all related to modules or how modules would have
prevented this.


> Consider:
>
>
> // far far away in another file entirely...
> import * from "foo";
> import * from "baz";
> console.log(x) // what?  where did THAT come from?
>
>
> The client chose to use *. You don't have to use * if you don't want to.
> It's a convenience.
>

For this, if it's actually that convenient, I'd actually suggest another
destructuring pattern, because it might be useful in general as well:

let * = Math;
console.log(PI); // 3.141592653589793
console.log(cos(0)); // 1

> x++; // do other importers of foo see x change? if so, spooky! if not,
> why not? is it foo's x or not?
>
>
> Clients are disallowed from mutating another module's exports. (That's one
> of the things we're able to accomplish by making modules declarative rather
> than totally dynamic.)
>

What about exported objects then? Are they immutable to clients as well?
That would make this unusable for libraries that have a plugin system, such
as jQuery.


> Dumping a bunch of symbols into my local scope is intrusive.
>
>
> The module did not dump anything. The client chose to bulk-import them.
> The client is perfectly free not to.
>
> Yes that is a fair statement.  I don't see how we can add typo
> checking without also adding "you get to tell me what to call my local
> vars".  In every other place in the language, I get to decide what my
> vars are called, and typo-checking happens locally, not at a distance.
> That's not a gap, that's a feature.
>
>
> Here I have no idea what you're talking about. Nothing about ES6 modules
> prevents you from locally controlling names. Local control over scope has
> always been one of the foremost principles of the entire design.
>
> Dave
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
Cheers,
Jussi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120627/b411f657/attachment.html>


More information about the es-discuss mailing list