modules: import hiding, and usage patterns
# Sam Tobin-Hochstadt (14 years ago)
On Wed, Feb 8, 2012 at 4:19 PM, Claus Reinke <claus.reinke at talk21.com> wrote:
Just saw this wiki update (*)
Before this goes further, I want to clarify that Dave and I are currently revising the wiki pages, and they're not done yet. We will announce something here when we're done, which should be soon.
Just saw this wiki update (*)
and this sentence:
I have two issues with this:
implicit override instead of ambiguity warning/error (add an explicit import, and change semantics of implicit imports elsewhere in the current module, without a type system to catch the change)
no way to filter items from the "*" form (can't resolve ambiguities explicitly)
I would prefer a way to resolve such ambiguities explicitly by selectively hiding imports (import * hiding {x,y} from M), with warnings/errors for unresolved ambiguities.
If there is going to be an implicit "import *" from a standard prelude, it would also be good to have a way to turn the implicit import into an explicit import (with selective hiding).
Great to see updates to the modules proposal - could you please have a look at the module usage patterns outlined in
It would be nice to see how these patterns will be handled by ES6 modules (I hope the answer isn't always "use loaders", but JS coders seem to have grown used to dynamic module usage patterns which don't seem covered by the static aspects of ES6 modules).
Finally, about the wiki: the list of old page revisions for each proposal links to page revisions, not to diffs - am I missing something, or could the wiki be configured to add diff links (to previous revision)? Also, the RSS feed still has escaped URLs, so the links do not lead to the intended page (*).
Claus
(*) the wiki RSS feed url escape problems still persist: esdiscuss/2011-April/013927
Just saw this wiki update (*) http://wiki.ecmascript.org/doku.php?id=harmony:modules&do=diff&1328732818 and this sentence: If there is a conflict between the names from two distinct imports, and exactly one of the imports uses the ''*'' form, then the other import takes precedence. I have two issues with this: - implicit override instead of ambiguity warning/error (add an explicit import, and change semantics of implicit imports elsewhere in the current module, without a type system to catch the change) - no way to filter items from the "*" form (can't resolve ambiguities explicitly) I would prefer a way to resolve such ambiguities explicitly by selectively hiding imports (import * hiding {x,y} from M), with warnings/errors for unresolved ambiguities. If there is going to be an implicit "import *" from a standard prelude, it would also be good to have a way to turn the implicit import into an explicit import (with selective hiding). Great to see updates to the modules proposal - could you please have a look at the module usage patterns outlined in supporting ES upgrading with a programming pattern repo? https://mail.mozilla.org/pipermail/es-discuss/2011-November/018240.html It would be nice to see how these patterns will be handled by ES6 modules (I hope the answer isn't always "use loaders", but JS coders seem to have grown used to dynamic module usage patterns which don't seem covered by the static aspects of ES6 modules). Finally, about the wiki: the list of old page revisions for each proposal links to page revisions, not to diffs - am I missing something, or could the wiki be configured to add diff links (to previous revision)? Also, the RSS feed still has escaped URLs, so the links do not lead to the intended page (*). Claus (*) the wiki RSS feed url escape problems still persist: https://mail.mozilla.org/pipermail/es-discuss/2011-April/013927.html