russell.leggett at gmail.com
Thu Jun 26 09:34:51 PDT 2014
> I like the fact that this doesn't look like destructuring, since variable
> binding is different from destructuring assignment. Could
> import foo, baz from "bar" as bar;
> allowed simultanous import of named exports and the module itself? If so,
> the grammar gains a pleasing regularity.
You know, I hadn't even thought of that, but yes, I think that could work
and be useful.
> OTOH, I think this syntax reorganization is orthogonal to some of the
> other issues discussed. In particular, your latter proposal still allows
> for user confusion between:
> import _ from "underscore";
> import "underscore" as _;
> The various proposals seem to try to address this by making these
> semantically identical (or near-identical, with some cooperation from the
> module author).
Default exports are confusing. No way around it. No other system that I
have seen really does it. If you look at the way node does default exports,
its really so much a default export as a module replacement. As in, instead
of giving you a module when you import, the system gives you that one
exported thing. I tried to mirror those same semantics, as I think that is
the only real argument for default exports. There is existing code in place
that uses those semantics heavily. If we are trying to pull from
experience, keep it consistent. The way to do that is to make default
exports get imported using the same syntax as module imports.
import _ from "underscore"; //looks like getting a member from the
import "underscore" as _; //looks like importing the whole module and
I don't think most developers will really understand the clear difference
between a module and a regular object and therefore won't seem weird if a
module is a function. They key point is - are you importing the whole thing
or a member of the thing.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss