> I wonder if you considered having an export list, rather than tagging the
> individual exports? I think that makes it easier to see/document the public
> API of a module. You could at the same time allow renaming on export.
Yes, this is a good point. We chose inline-export for convenience, but I don't
see any reason not to allow both.
> FWIW, the rename on import looked "backwards" to me at first glance, but I
> think I can learn.
Yeah, I'm not thrilled about how hard it is to remember which way it goes. I
meant for it to be consistent with the syntax of destructuring:
let { draw: d } = obj;
import M.{ draw: d };
> Do we really need to say `.*` for all? We couldn't just say `import Math`?
The proposal originally left out the '.*' and others didn't like it. But more
importantly, this has subtler implications for nested modules, e.g. what the
meaning of the following example is:
module Outer { module Inner { ... } }
import Outer.Inner;
The way we've written the proposal, any time you import a path without the
'.{...}' syntax, you're importing a single binding. So import Outer.Inner is
the same as
import Outer.{Inner};
That is, it binds Inner locally to the Outer.Inner module instance.
Alternatively, we could a) disallow leaving off the '.{...}' for importing a
single binding and 'import x1.---.xn' would only be allowed to specify a
module-binding and would import all its exports, or b) allow leaving off the
'.{...}' but specify that it imports just the single binding when it's a
value-binding and imports-all when the path indicates a module-binding. I am a
little concerned that the former is too restrictive and the latter too subtle.
IMO. the extra '.*' is only a two-character hardship and EIBTI.
Dave
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
