Import concerns revisited

[Walter Bright]

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

I really don't understand your pov. I can't help but think you regard 
alias as like C++'s #define:

	alias foo bar;
	#define bar foo

Such #define's I would agree are a terrible hack that don't belong in 
professional code. But aliasing isn't like that, it's a sane and 
well-behaved replacement.

> 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.

With the "static import", there is no longer any possibility of name 
collisions, so we're not at square one. With no aliases, fully qualified 
module contents lookup will be needed.


> 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?

I don't see it as arcane or a workaround. Symbolic aliasing is a very 
powerful feature - yet it's very simple.


> 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;
> 
> ==================================

But those *are* aliases. It's just using a different keyword, "as" 
instead of "alias", and a slightly rearranged syntax. So what's the 
difference between:

import lib.text.locale.Time as otherTime;

and:

alias lib.text.locale.Time otherTime;

? Absolutely none, unless I am totally misunderstanding your proposal.


> 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?

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

      // selective import
static import lib.text.locale;
alias lib.text.locale.Time Time;
alias lib.text.locale.Date Date;
auto time = new Time;
auto date = new Date;

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

These are semantically identical. The "static import" is a bit ugly 
looking, ok. It's a little wordier, ok. But it does work and produces 
exactly the results you asked for.

Let's harken back to the special regexp syntax I tried out a few months 
ago. It was a bit of syntactic sugar that reduced typing significantly. 
But it was soundly rejected by the community as adding complexity (in 
the form of more language to learn) while actually adding little to no 
extra power.

The "with" and "as" syntaxes add no power - they just save a little 
typing at the expense of adding more complexity to the grammar. Is that 
a worthwhile tradeoff? I don't know, but my inclination is to be 
conservative about such things.

I suggest trying out the "static import" for a while. See how it works 
and looks.