What is the behavior if a module doesn't define a default export and the syntax
for importing the default export is used?
What is the behavior if a module only defines a default export and the syntax
for importing named imports is used?
---
R. Mark Volkmann
Object Computing, Inc.
> On Jun 19, 2014, at 3:15 AM, David Herman <dher...@mozilla.com> wrote:
>
> Thanks to everyone for working through the issues around ModuleImport. I know
> it's been frustrating, but the discussions have really helped clarify the key
> constraints.
>
> ## Constraints
>
> First, let me restate the most important arguments. In favor of removal:
>
> * **The syntactic distinction between ModuleImport and default import is
> vague.**
>
> We've consistently seen confusion between the semantics of ModuleImport and
> default export. While certainly some of the confusion might be chalked up to
> misinformation and lack of documentation, we've seen people be confused by
> this even when correctly explained the semantics. The problem with the syntax
> is that the only visual distinction is the initial keyword (`module` vs
> `import`), and it's not clear from that keyword which concept you're talking
> about. (Once you've internalized the structure of module instance objects,
> you get a hint from the `module` keyword, but that doesn't help people who
> are just learning the system, particularly if they're already familiar with
> other JS module systems.)
>
> Against removal:
>
> * **Without ModuleImport, authors of multi-export modules would be pressured
> to circumvent the named exports functionality.**
>
> Without ModuleImport, clients of multi-export modules have two options.
> Either they use named import:
> ```js
> import { readFile, writeFile } from "fs";
> ```
> or if they want to explicitly namespace those functions, they have to use the
> dynamic API:
> ```js
> import "fs"; // state the dependency
> var fs = this.get("fs");
> ```
> That's inconvenient, confusing, and makes you feel like you're stepping
> outside the normal usage patterns intended for the system. Since this is a
> choice forced on the clients of a module, the module author will feel
> pressure to circumvent the named export feature altogether and instead export
> a default object with all the properties. This is bad -- it creates pressure
> for people to abandon part of the module system.
>
> ## Conclusion
>
> Here's the conclusion I've come to based on all of the above.
>
> * **We need a form like ModuleImport.**
>
> As many have said, clients of named-export modules need the freedom to choose
> whether to explicitly namespace those imports, and they need a syntax that
> doesn't feel like they've stepped outside the normal system.
>
> * **The current syntax of ModuleImport is wrong.**
>
> The confusion reported in developer feedback is real, and it's important.
>
> * **The syntax should still favor default import.**
>
> ES6 favors the single/default export style, and gives the sweetest syntax to
> importing the default. Importing named exports can and even should be
> slightly less concise.
>
> * **A better ModuleImport syntax is possible, and we should settle it soon.**
>
> I'll propose a better ModuleImport syntax below. Syntax being syntax,
> everyone will of course unsheathe their bikeshed paintbrush. That's OK. The
> champions will keep it from going on unbounded and help settle the debate,
> and we'll make sure to capture the conclusion in the next TC39 meeting.
>
> I do acknowledge the concerns about reopening topics for debate and delay.
> But given the usability feedback, I think this case is worth fixing. We
> should resolve it for ES6, perhaps in part because it's less editorial work
> to change the ModuleImport production than to defer it, but more because I
> don't want to delay the resolution so that implementations can ship the
> better syntax. But keep in mind it doesn't matter what spec it lands in as
> long as implementations are shipping it. We're still in the early days of
> transpiler implementations, and there are no native implementations of
> modules yet. So there's time, as long as we don't let the bikeshed go on
> forever. So let's get to it!
>
> ## Proposal
>
> OK, so we're talking about a better syntax for importing a module and binding
> its named exports to a variable (as distinct from importing a module and
> binding its default export to a variable). Here's my proposal:
> ```js
> import * as fs from "fs"; // importing the named exports as an object
> import Dict from "dict"; // importing a default export, same as ever
> ```
>
> Why is this better? Because it dovetails with the named export syntax,
> **which makes it clear that it's binding `fs` to the named exports.** It
> saves the reader from having to know that the module instance object is not
> the same thing as the default export.
>
> So there you have it... Feedback welcome, and as always we'll collect it all,
> weigh it, and try to shepherd consensus.
>
> Oh, and just to put parameters on the discussion:
>
> * **I'm not proposing additional new import forms.**
>
> If this syntax is future-compatible with other possible syntactic forms,
> that's great, but that's not what we're discussing.
>
> * **I'm not interested in discussing changes to the rest of the module
> syntax.**
>
> This isn't the time or place to redesign the whole system.
>
> * **The `this` binding in modules is a separate topic.**
>
> The `this` binding in modules can be discussed independently of this topic.
>
> tl;dr we're only talking about the ModuleImport syntax here.
>
> Dave
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
