modules, @std, selectively hiding/renaming imports
claus.reinke at talk21.com
Fri Nov 25 02:02:02 PST 2011
>> From the early drafts of a standard library
>> 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
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?).
More information about the es-discuss