> 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss