Import concerns revisited

[kris]

Walter Bright wrote:
> kris wrote:
>> I suspect you are very confused about what is actually being asked 
>> for. Is that the case? Perhaps you'd like to note what it is that you 
>> think is being proposed?
> 
> 
> You prefer:
> 
>     with Foo import bar as abc;
> 
> instead of:
> 
>     static import Foo;
>     alias Foo.bar abc;
> 

As I suspected, you've been thoroughly confused by the sheer variety of 
options. What /I've/ been asking can be broken down into two parts:

part 1.

import lib.text.locale.convert as convert;

This imports all of the convert module symbols, and makes them available 
via a "locale." prefix. This is equivalent to your "static import" in 
conjunction with a relevant alias.

Replace the keyword "as" with ':' or '=' as desired.

-------------

Part 2.

This second aspect is entirely optional. It came about based on your 
initial suggestion, and imports distinct symbols instead of all:

import lib.text.locale.convert.Converter;

For those who want to rename it at the same time, append the "as" 
syntax. The rename might be used to resolve the conflicts within phobos, 
for example. Again this selective-import is secondary ~ that should have 
been made clear from the beginning. It would be wonderful to have this 
selective-import along with the former style, but given the current 
circumstances I'd say it can happily be dropped in favour of the former.

---------------


> 
>>>>  > 2) how much power it adds
>>>> It adds the ability to import specific symbols - a quite powerful 
>>>> addition to import I think.
>>>
>>> But that power already exists. 
>>
>> One can import only specific symbols at this time? Really?
> 
> 
> Import does not import names into the current namespace. It imports them 
> into a secondary namespace, that is looked in *only* if the name isn't 
> found in the current namespace. Alias can then cherry-pick specific 
> symbols out of that secondary namespace and put them in the current 
> namespace, possibly renaming them along the way. (Python's documentation 
> calls that "binding" a name into the local symbol table, but it's the 
> same thing.)
> 
> With 'static import', the names aren't even put into the secondary 
> namespace. Unaliased, they can only be accessed as FQN's. An alias can 
> then be used to bind individual symbols into the current namespace.

I see; and this will encourage developers to use the safer approach?


> 
> (*) And yes, you can still access the other names in the static import 
> via FQN's. A couple posters thought that might be a problem, but:
> 1) I doubt many are going to accidentally type in a FQN;
> 2) FQN's are not going to produce name collisions unless you happen to 
> name your symbols the same as the topmost package name, which is just 
> not realistically going to be a problem.
> 
> 
>>> The discussion is now about whether two statements should be combined 
>>> into one or not. The power is the same.

Yes, it is. But not for the reasons you think. You clearly feel it's all 
about aesthetics, for something that will be used rarely.

I feel it's more to do with ease of use, ease of maintainablity, and 
ease of comprehension at a glance.

Furthermore, I feel it is not something that will be used rarely at all. 
Instead, the safe import should be used at /all/ times by those who wish 
to avoid the otherwise inevitable potential for namespace collisions.

This latter observation basically dictates that commercial software 
houses should not use the existing import, given its notable 
susceptibility to namespace collisions in anything other than small 
projects. Instead, they should use the /safe/ import at all times. 
However, you insist they should then either use FQS at all times, or 
alias every one of those safe imports.

Yes, I understand that you feel this aspect is utter nonsense. But then, 
compared to some people here, your experience in such things is not 
necessarily the most applicable ~ how can you possibly expect it to be?

The same thing happened with Associative Arrays: you didn't bother to 
solicit opinion on either of the two occasions when it was changed; and 
then subsequently complained when people still found issue with you 
alternate changes. It's still not right to this day. I see the same 
pattern here. And for what?

Anyone would think we were trying to sabotage the language, when instead 
we're trying to get it into the shape needed for us to introduce it 
within the corporate realm.