import concerns (was Re: Historical language survey)

[Walter Bright]

kris wrote:
> Walter;
> 
> I added compilable code at the top of the post here, in a genuine 
> attempt to show you where the current design has a weakness. Yet, you 
> ignored those clarifications entirely. Focusing instead on pre-clarified 
> observations, which could be considered somewhat ambiguous, doesn't help 
> much at all :(
> 
> The code provided illustrates the weakness quite well. I do hope you'll 
> run the example provided, and address that instead?

I want to make sure first that all understand how it currently works, 
and that the way it works is neither a bug nor erratic.

The following two suggestions:

>>> One way to avoid the re-engineering is to use
>>> "import wumpus as ...."
>>> "import bar as ...."
>>>
>>> Another approach is to import explicitly, just like Modula-3 does:
>>>
>>> import Bar from bar;
>>> import Wumpus from wumpus;
>>>
>>> In this case, it's pretty clear than any additions to modules from 
>>> either vendor will not result in re-engineering work. It's also a bit 
>>> closer to the current D model.

suggest the onus is on the importer, not the importee.

>>>> Yes, I'm aware of those various workarounds, but none of them 
>>>> address the issue. As I'm sure you're aware of, all of these need to 
>>>> be used at the import site ... not in the importee code. This is 
>>>> where the issues arise.

But the proposed improvements involve changing the importer code.


>> Not if you use either fully qualified names when importing, or you use 
>> an alias to pick which Bazooka you want.
> 
> The whole point of this particular thread is to avoid needless 
> modifications to code which imports other modules; where those /other/ 
> modules change over time.

But the suggestions involve changing the importer code, too. I'm not 
seeing the advantage of that over fully qualifying the references or 
using an alias, both of which will ensure that no future imports will 
cause name collisions.


> That's exactly why I added the working code examples at the top of the 
> post -- so you could try it out with the compiler, and observe for 
> yourself what it does. It demonstrates that the current import handling 
> is really quite brittle from a large-scale and/or long-term development 
> aspect. Please read the clarifications toward the top of this post.

I know exactly how it works, and it's working as designed (I wish to 
emphasize the way it works is as intended - it's not a bug and alias is 
not a workaround). The current module scope overrides any imported 
symbols, and if a symbol is not in the current module scope but is in 
more than one import, an ambiguity error occurs (because all imports 
have equal standing, none is favored over another).

What can be done is something like add a warning whenever a name is 
found using the second-class import lookup, rather than using an alias 
or a fully qualified lookup. Then, you'll be able to easily purge your 
code of any such, and be confident that adding other modules will not 
break your existing code.

What can also be done is extend the import declaration to allow the .'s 
to continue so that specific symbols can be imported.