**lltp:** _Well, then it is useless. I am from a domain (science) where similar
concepts are generally called a similar way and where clashes occur a lot
because something as simple as * has a gazillion meanings depending on the
context (and all of them applied to arrays of any dimensions, so no useful
dispatch there)._
As somebody who works in the same domain, may I suggest that qualifying
everything may not be the way to go here?
A better solution would be ML-style module management, especially local
imports. This allows you to write things like: `Vect3D.(x + y + z)`, where the
imports from the module `Vect3D` are only visible within the expression in
parentheses. It would be a bit trickier to do in Nim (because Nim does
overloading rather than shadowing), but those issues can be solved.
**Araq:** _I will do so if you ask again, but as peace-offering how about this
proposal:_
from Module import type Foo
While I'm not opposed to that idea, something I'd rather see (or in addition)
is an option to declare and import parts of a module.
We have to look at the actual problem we'd like to solve. Normally, a
well-designed module should not be a kitchen sink and just contain a type (or
set of tightly related types) and its operations. A `from M import type T`
statement would then simply be the same as `import M`. Problems arise if either
(1) we end up with a kitchen sink module despite our best efforts, (2) two more
modules are so interdependent that they cannot be separated into several module
files, or (3) parts of the module (such as support for testing or for a DSL)
are only needed sometimes, but not all the time.
In short, regardless of whether it would be valuable to support selective
imports on the client side, specifying selective imports on the supplier side
is at least equally (if not more) interesting.
