Import concerns revisited

[kris]

Walter Bright wrote:
> 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.


That's assuming anyone would use it? Who's gonna do that when you insist 
that (a) they have to always use the FQN for safe imports or (b) use an 
alias along with every static import?

Suppose people actually used static-import? We'd start migrating to the 
shortest import paths possible to avoid the long names, or have an alias 
sitting beside every import.

These two belong together ~ the idea is to /encourage/ people to use 
this safer alternative, not turn them away.


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


Perhaps you ought to stop for a moment and take a look at all the people 
here asking you to combine these features together? Then go back over 
the last two years and just count how many posts there are about this 
one specific aspect: import. Do we really have to beg? Does D go where 
the community wants it to? Take a look at /all/ these posts ~ please?


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


Under the covers? Does it matter?


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


And at the cost of making life harder for anyone who has to work on a 
large-scale project containing hundreds or thousands of modules. Without 
being disrespectful, I have to ask when was the last time you worked on 
a large-scale application with more than three people involved? Now how 
about several million lines with 500 engineers? Do you really want them 
plonking aliases all over the place when it's basically trivial for the 
compiler to deal with this in a clean and precise manner? Isn't this 
wehre you want D to be? Or is it intended to compete with Python only? 
(and IIRC python actually has a better import system).

Skip to the next section if you want to avoid overflowing frustration.

I don't get it, Walter. I really don't. I would have thought you'd be 
more that considerate toward making things easy for the end-user, but 
you seem to be insisting they take multiple steps with something that 
pretty much /every/ module will do multiple times: import other modules. 
To do so in the safest manner possible should be made as easy for the 
user as possible. Not in some manner that discourages anyone from using 
the safe approach.


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


Just don't know how I can explain this to you in a way that you'll 
understand; But I'll give it one last try:

* Regex is used rarely in modules. Even in apps with heavy regex usage, 
the functionality tends to get wrapped anyway. On the other hand, import 
is used in pretty much every module. It's something that's almost always 
there, and the safest manner of using import should obviously be made 
easy to use, easy to follow, and easy to maintain.

* Regex is perfectly suited to library functionality. One cannot do that 
with import ~ it's part of the module declaration. Isn't that the case?

* Embedding Regex in the language itself tend to reduce the motivation 
to provide alternate implementations. The Template Regex is just one 
such example, which you proudly displayed at a presentation. I don't 
think import can really be compared to this aspect either; can it?

The embedded regex was rejected for at least the latter two reasons, and 
not because it added extra complexity to learn the language. Given that 
import will be used mutliple times by pretty much every single module, 
and Regex by almost zero in comparison, it would appear overtly reckless 
to consider them as equivalent in any form or manner.

======= idea =========

Perhaps we should count how many imports there are in the current D 
language base, and then compare that to the number of import std.Regex? 
What would you guess? Perhaps 5000 to 1? Maybe 100,000 to 1? Perhaps 
more? How many does it have to be?

I truly hope this makes the distinction clear enough for you?

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


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

I earnestly suggest you consider how many people are currently and have 
been asking for you to address this concern, and to place overall 
usability of daily-language usage above whatever is stopping you from 
considering this beyond the need for yet more alias usage.

Think about it ... import is used /all/ the time. Perhaps an average of 
three times per module? Would you rather make the safe method of import 
hard to use, or easy to use?