Import concerns revisited

[Kirk McDonald]

kris wrote:
> 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?
> 

Yes! All of this is good.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki