import concerns

[kris]

Dave wrote:
> Andrei Khropov wrote:
> 
>> Walter Bright wrote:
>>
>>> There's another way - have a different kind of import declaration, say,
>>> precede it with static:
>>>
>>>     static import foo;
>>>
>>> which will make the symbols in foo available, but only if they are 
>>> explicitly
>>> qualified. Then one could access bar in foo by either:
>>>
>>>     foo.bar();
>>>
>>> or:
>>>
>>>     alias foo.bar bar;
>>>     bar();
>>>
>>> but not:
>>>
>>>     bar();    // error, undefined symbol
>>>
>>> The advantage of this is it is a bit more flexible and more 
>>> consistent with
>>> the way the rest of D lookups work.
>>
>>
>> That's what I was talking about in
>> http://www.digitalmars.com/d/archives/digitalmars/D/39348.html
>>
>> Finally got a feedback from Walter :-)
>>
>> Looking forward to see this in future releases.
>>
>> "as" would be nice too but it's just syntactic sugar for fqn import + 
>> alias.
>>

hehe -- this wandering thread goes all over the ng. I'm moving this 
reply out of the gdc forum :)

the problem with the above is that the static-import would require all 
references to be "fully" prefixed. It looks ok on paper, but you'd end 
up with some very long names for references. It could be limited to use 
only the module name itself, and discard the path prefix e.g.

static import lib.text.locale.time;

auto time = new lib.text.locale.time.Time;  // where did the Time go?
auto time = new time.Time;                  // module name only
-----

but perhaps a better solution for this would arguably be

import lib.text.locale.time as quick;      // use a name of your choice

auto time = new quick.Time;
-----

Unfortunately this introduces a new keyword, "as".

There again, both these approaches are importing all symbols from the 
module; whereas the other proposal that most people seemed to like is an 
extension to /selectively/ import instead:

import lib.text.locale.time.Time;

auto time = new Time;
-----

This is clearly more explicit. There are benefits to both approaches, 
and while I'm in the latter camp as being the better overall solution, 
I'd really like to see both available :)

For example, as a library writer, I'm one of those who leans heavily 
toward grouping so-called free-functions into a namespace of their own. 
e.g. I'll use a struct to wrap a set of otherwise free-functions, just 
to give them a namespace. Some folk here would have a fit over that, but 
I do it to avoid the subtle namespace clashes that arise within other 
libraries. I'd be happy to drop that particular habit/workaround if the 
static-import were available (with the module-name-prefix only i.e. "new 
time.Time;"). This would work particularly well for nifti modules (Nifty 
Implicit Function Template Instantiation), and would avoid the one 
problem with using structs for namespace resolution -- which is that the 
linker cannot strip unused functions from a struct, so you may end up 
with some unused code in the executable. That kind of thing should 
really be avoided for nifti modules in particular.

But the selective import is still the more elegant solution, in my book. 
So if we had only one choice, you know where I'd be. If we can have 
both, then that would be even better. Too many choices is often a bad 
thing, but it this case each approach appears to have true merit, and 
its own place in creating robust and easy-to-manage code. If one or the 
other has a serious technical impediment, then that would have to be 
considered - obviously.


> Yes, but the syntactic sugar in this case might be a lot of bang for the 
> buck if it's easy to implement along with allowing specific symbols to 
> be imported. 'as' is much easier for newbies to D to grasp, turns 2 
> lines of code into one *and* makes it easier for maintainers to spot as 
> they scan the imports (because aliases can and will be buried anywhere).

Yes, I fully agree. Alias can be useful, but it shouldn't be overused 
(like goto, I suppose; or champagne). It would be hard to keep track of 
imports that are aliased here and there, and the extra step involved 
(with adding an alias) would hardly be conducive to /encouraging/ 
namespace seperation. These might seem like small concerns to some, but 
within large bodies of code they really do make a notable difference.