Import concerns revisited

[kris]

Walter Bright wrote:
> Kris wrote:
> 
>> Er, that really doesn't work at all. Please ignore what I said a few 
>> minutes ago
>> regarding this option (I really should get some sleep instead).
>> The problem here is that, for the proposed static imports, everything 
>> must be
>> fully-qualified with the /original import name/, and that's just plain 
>> awful for
>> long import names. The "import as" allows one to give it a nice short 
>> name
>> instead.
> 
> 
> Alias also works fine for making substitutes for long, awkward names:
> 
> import x.y.mod;
> alias x.y.mod t;
> 
> x.y.mod.foo();    // works
> t.foo();    // also works
> 
> 
>> And, I still think the selective-import is the superior solution anyway.
> 
> 
> Semantically, it isn't any different. It would even be implemented 
> internally using the 'alias' machinery.

Hrm;

The use of alias, regarding imports, should very likely be kept to a 
bare minimum in anything other than Q&D development. Ideally zero.

It's like the use of goto ~ use it where it can really help, but 
otherwise consider alternatives instead. I don't know what kind of 
development-scales you have in mind for D, but I'll happily testify that 
a boatload of aliases littering the imports would have no place in any 
project I'm responsible for; nor in those of the people I learned from. 
Here's why:

Quantities of alias do little but complicate ones comprehension of the 
code. Having a second-step (import then alias) is not only messy for 
each import, it does nothing to /encourage/ smart usage of namespace 
seperation. In fact, the extra step will likely discourage everyone but 
the diehards from using anything but the current global namespace, and 
we'll end up right back at square one.

At that point, the language would be lacking. And why? This is all about 
maturity and usability of the language in specific areas. Why the 
rollback to something that can be considered "arcane" instead?

Hey ~ if you'd actually roll in the changes, I'd be happy to make them 
myself ... I'd add both selective import and the "as" variation ~ a 
flexible combination to handle all cases, including the one Derek 
astutely pointed out. No aliases required by the user:

// import as we know it today, and with a required prefix "locale."
import lib.text.locale;
import lib.text.locale as locale;

// selective import of one entity, and alternatively with an alias
import lib.text.locale.Time;
import lib.text.locale.Time as otherTime;

==================================

Okay. Let's reflect for a moment?

The functionality is there, but the syntax could probably be better? 
There's a number of other posts proposing the use of "with" and so on, 
which look rather promising (from Kirk & Derek):

with lib.text.locale import Time, Date;

Seems pretty darned clear what's going on there. Seems to me that's a 
much more user-focused solution for selective imports. Let's combine 
this with a means to import an entire module under a prefix, as we've 
previously seen:

      // import as we know it today
import lib.text.locale;
auto time = new Time;

      // "locale." prefix required (great for IFTI modules)
import lib.text.locale as locale;
auto utc = locale.utcTime();
auto dst = locale.daylightSavings();

      // selective import
with lib.text.locale import Time, Date;
auto time = new Time;
auto date = new Date;

      // selective import with alias
with lib.text.locale import Time, Date as MyDate;
auto time = new Time;
auto date = new MyDate;

==================================

How about it?