From the early drafts of a standard library
http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard
it appears we are headed for an import name clash between
"Object.keys and "@iter.keys" - they cannot both be available as
plain "keys".
Object is not a module, so there's no clash. Lots of methods named "keys"
these days.
Also the recent es-discuss thread on @iter suggests eliminating it in
favor of @reflect, which we want for Proxy helpers too.
Perhaps I misunderstand the standard library idea: I thought
the idea was to provide those identifiers in unqualified form,
via an implicit import-* of "@std" (btw, is there a way to turn
of the implicit import, making it explicit, for more selective
import?).
The "keys" from "Object" and from "@iter" can't both be in
scope, yet both "Object"/"@reflect" and "@iter" seem to be
scheduled for inclusion in "@std".
While the standard library needs a separate resolution, this
situation is not at all untypical for module-based development.
How are ES.next modules going to deal with this? We can locally
rename an imported id, but I see no facilities for import hiding
(import everything but a handful of ids), so how would we import
everything while renaming a few ids?
We've mooted syntax for selective renaming, but import-all (import * from
"...") lacks that feature in the current proposal. You'll have to be
explicit in what you import.
This ok. * imports are for prototyping, one-offs where you control both
modules, and the like. They are not for everything. And anyway, there's
non conflict with Object.keys.
I agree that explicit imports are better for documentation, and
for being selective about dependencies when we don't control
the imported module. Though it is inconvenient for development,
one can write tools that alleviate this inconvenience. And the
sooner one documents which module an item comes from, the
one will have to search later.
However, I'm not sure that JS coders in general will like the added
formality, and without selective renaming, import-* cannot be
used at all in the presence of possible name conflicts.
Assuming, for instance, that two modules A and B both export
"keys", one could not import-* both, not even in prototyping.
And if there is no way to turn an implicit 'import * from "@std"'
into something more selective, names such as "keys" will not
be available anyway (or do later imports shadow earlier ones?).
Claus
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
