On Tue, Jun 24, 2014 at 9:26 AM, Kevin Smith <zenpars...@gmail.com> wrote:
>> Ron Buckton's suggestion above makes the most sense to me personally. And
>> I saw many people arrive to a very similar idea a few times in these
recent
>> module threads - but it kind of always gets rejected with no substantial
>> reasoning.
>
> I'm not really sure what Ron's proposal is, but I'm going to assume that
the
> suggestion is to have the default "default" be the module instance object.
Quoting Ron's proposal:
[W]hy not simplify the syntax and semantics to just the following three
> forms:
> ```
> import "module"; // imports the module but does not perform binding
> import name from "module"; // imports the module (either the default
> export or a module object with the named exports, see below)
> import { name1, name2 as "otherName" } from "module"; // imports members
> of the module.
> ```
> Simplifying this requires the following (approximate) changes in semantics:
> * Either (A) a module cannot have *both* a default export and named
> exports, _or_..
> * (B) A modules named exports become attached properties of the default
> export if provided.
> * If (B), it becomes an runtime error to add a default export after a
> named export, and a runtime error to add a named export if the default
> export is not an Object.
> ** The ImportBinding (`name` above) becomes bound to a [[Value]] property
> of an (not part of the current spec) Import exotic object.
> ** When the Module exotic object is loaded, if it has a property named
> "default", that becomes the value of the [[Value]] property of the Import
> exotic object.
> ** If the Module exotic object does not have a property named "default",
> the Module itself becomes the value of the [[Value]] property of the Import
> exotic object.
> ** NamedImports now points to bindings to the [[Value]] property of the
> Import exotic object. If you want both a default export and named exports,
> attach the named exports as properties of the default export.
> With the above changes, whether you're using a default export or named
> exports becomes transparent to the developer. If the developer _really_
> wants the module object, they could fall back to:
> ```
> import "module";
> var name = System.get("module"); // Returns the Module object without the
> transformations applied from above.
> ```
I favor (A) for ES6. I believe option (B) can be added later. (It's easy
to later allow things which we initially forbid.) In my ideal world, (B)
would be added in ES7ish as part of a more general "binding destructing
mechanism". (That is, currently the only way to get magical lazy bound
identifiers is via an import of named exports from a module. But in the
future there might be other ways to do that which would be consistent with
the way that named exports are bound to a default export object when both
named properties and a default export object are used.)
> The reason why that's problematic is that it makes adding a default export
> at a later date a breaking change for consumers of the module. You would
> essentially have to decide whether your module is going to have a default
> export (other than the module instance object of course) when you first
> create it and never change it thereafter.
Lots of things are breaking API changes. Changing the name of one of the
named exports, for instance. Critically, in Ron's proposal, you *can*
change a default export to named exports later (or vice versa) *without
changing the users of the module*.
--scott
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
