import concerns (was Re: Historical language survey)

[Sean Kelly]

Walter Bright wrote:
> kris wrote:
>> D imports an entire module, into the current namespace (or some 
>> variation upon that). This means that any additions to the original 
>> module have to be aware of the namespace usage of *any* module that 
>> imports the original. Otherwise, a namespace collision will occur and 
>> the combination will fail to compile. M3 import explicitly from each 
>> module instead ~ you can't have such a collision. The value of that is 
>> just as solid today as it was in 1989.
>>
>> One might argue that with D, one should create new modules instead of 
>> extending existing ones? That's a fair point until you consider that 
>> the module namespace is limited to one file, and the 'friend' aspect 
>> is limited to one module (private attributes being visible within the 
>> one module). Thus, D suffers this problem in a notable manner.
>>
>> I forget whether M3 supports importing into a distinct namespace or 
>> not --- the "import x.y.z. as foo;" syntax -- but that can alleviate 
>> related problems, and would help resolve the current D namespace 
>> conflicts that are quite prevalant?
> 
> import namespaces are second class citizens in D - they are easily 
> overridden by using aliases or fully qualified lookups:
> 
> import a;    // defines foo()
> import b;    // defines foo()
> 
> foo();        // ambiguous
> a.foo();    // doesn't matter if there's a b.foo
> b.foo();    // works
> 
> alias a.foo foo;
> foo();        // works
> 
> As for import x.y.z. as foo;, you can do:
> 
> alias x.y.z foo;
> foo.bar();
> 
> alias x.y abc;
> abc.x.bar();
> 
> alias x def;
> def.y.z.bar();
> 
> The alias works at any level you choose to make it. Alias can be used to 
> 'import' any name into the current namespace, making it first class.
> 
> The second class lookup capability is to make it easier to write quick 
> and dirty programs. Aliases or fully qualified names should be used when 
> writing large, complex apps. Think of it like using private - you 
> wouldn't bother with it for small or throwaway programs, but you 
> wouldn't think of not using it for long lived or complex apps.

I like the second class lookup capability as it leads to clear and 
predictable behavior.  And I agree that 'alias' is a very useful tool 
for handling more advanced requirements.  Kris does as well, I beleive, 
as the "import x.y.z as foo;" proposal was meant as a shorthand for:

     import x.y.z;
     alias x.y.z foo;

With the issue of whether the contents of x.y.z are visible without the 
'foo' qualifier as an open issue (IMO).

However, the current lookup rules are such that the need to alias or 
fully-qualify names is really quite common, and it is confusing for 
those new to the language.  For example:

     module modA;

     void someFunc() {}

----------

     module modB;

     private void someFunc() {}
     void doSomething() { someFunc(); }

----------

     import modA;
     import modB;

     void main()
     {
         doSomething();
         someFunc();
     }

Compiling the above gives:

     modA.d(3): function modA.someFunc conflicts with
                modB.someFunc at modB.d(3)

Thus requiring the user to fully qualify his call to someFunc even 
though the collision is with a function that he shouldn't be aware of in 
the first place.

Now I'll admit that I used to fully support the current lookup 
mechanism, but I've since used D a lot more and this issue has bitten me 
quite a bit since then.  So I decided to do some digging and discovered 
that the lookup mechanism for C++ classes (which the D mechanism is 
obviously based on) was done mostly for practical reasons to deal with 
compiling out-of-class member definitions, and that the current 
suggestion for modules in C++ includes making module-level declarations 
truly invisible to importing modules (the original post is here: 
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39072).

I have no intentions of suggesting that the import mechanism be 
fundamentally changed from how it works now, but is there any chance 
symbol lookup and visibility rules could be examined a bit before 1.0? 
I know others have brought up related problems in the past regarding 
mixin visiblity rules and such as well, and perhaps it would do to 
establish whether things could be tweaked a bit to resolve these 
complaints without pressing for a sea change?


Sean