An excellent post.  I feel much the same as Sean about the reason it is so difficult to "convince" in relation to the import syntax issue.  It is about aesthetics to a great extent.  But I think the aesthetics are very important in this situation because it decides how D appears to those trying to understand the language.

I aslo share Seans feelings concerning the alias attribute.  "alias" is a great addition to the D langauge.  Perhaps I was unclear in my last response to Walter: alias, in itself, is not a hack in the general case.  But I believe it is laborious and ugly when used in the context of modules and imports.

D should be elegant.  Using alias and static import comes across as a verbose workaround when one is working with multiple module imports; in all other cases, it may be equivalent, but I think it's just plain ugly in comparison to the alternative syntax using with/as or from/as.  It accomplishes something that could be greatly simplified with an addition of a minor syntax expansion.

-JJR

In article <e8rk68$1fat$1@digitaldaemon.com>, Sean Kelly says...
>
>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.
>
>I think Kris was merely suggesting that the need for a separate alias declaration for each import was the problem, not the idea of aliasing itself.  If a particular module imports 10 others, that's 10 separate aliases required as well, and there's no good way to write them in a way that makes for easy readability and maintenance.  This is the point he was trying to make below.
>

<snip great post content>

Sean Kelly wrote:
> Kirk McDonald wrote:
>> I actually feel the best solution is full-on Python-style imports, with "from" and "as", and "import" meaning FQN import. The only thing I think is stopping it is the introduction of two new keywords and the fact that this change in semantics would totally break essentially all existing code.
> 
> Why is that?  Wouldn't the old import syntax still be available?  Or are you concerned about the addition of 'from', 'with', or 'as' as keywords?

No, I am saying I prefer pure fully-qualified imports, the way Python does it. I'm saying it would have been better if D had done this originally:

module foo;
int bar = 20;

module mymodule;
import foo;

writefln(bar); // ERROR!
writefln(foo.bar); // Okay

The point of FQN imports is that you cannot introduce a name into the current namespace without explicitly saying (at least once) where it came from.

But this would obviously break existing code if it were changed now. Therefore, a new, different form of "import" is required to mean FQN import. I suggested "static import," with the reaction we have seen.

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

Derek Parnell wrote:

> *Please* do not overload the "static" keyword with yet another definition.

I generally agree.
 But I think it wouldn't be a big problem if we get used to it.
Anyway an alternative is to introduce some new keyword, isn't it?

-- 
AKhropov

Derek Parnell wrote:

> Why not join the two ...
> 
>   import x.y.mod alias t;
> 
>   t.foo();

Not bad

-- 
AKhropov

"Walter Bright" <newshound@digitalmars.com> wrote in message news:e8pl56$26u9$1@digitaldaemon.com...

> Turns out, "scope" was a problem. It broke a lot of my code - a lot more than I'd anticipated.

Heh, of course, the "scope" statement came out just as I was beginning to write the MiniD compiler :S  Had "scope" in there quite a few times!

Okay, no one seems to like "static import."  How about "protected import"?

It fits right in with the current syntax:

public import foo; // the default
private import foo;
protected import foo; // FQN import

And it says "protected," as in "the names are protected from conflict by their namespace."

The only problem I'd see with this would be doing a "private protected import" :S

Sean Kelly wrote:
> Dave wrote:
>> John Reimer wrote:
>>> In article <e8qjkf$2tqc$1@digitaldaemon.com>, Walter Bright says...
>>>> Ivan Senji wrote:
>>>>> Sure I could use
>>>>>
>>>>> static import m2;
>>>>> alias m2.func f2;
>>>>>
>>>>> And that would be an improvement but it is still longer (and arguably
>>>>> less understandable) than:
>>>>>
>>>>> import m2.func as f2; ;) :)
>>>> Let's say you're going to do more than one:
>>>>
>>>> static import m2;
>>>> alias m2.func f2;
>>>> alias m2.abcd f3;
>>>> alias m2.efgh f4;
>>>>
>>>> vs:
>>>>
>>>> import m2.func as f2;
>>>> import m2.abcd as f3;
>>>> import m2.efgh as f4;
>>>>
>>>> Not much of a difference. I'm also not understanding why alias is hard to understand.
>>>
>>> Well, your example is just showing selective renaming from /one/ module.
>>> Naturally these two are going to be very similar.  Please look at Kris'
>>> suggestion, thoroughly.  The whole system is vastly superior once one starts
>>> referencing selective importing from multiple modules.  The total number of
>>> lines are cut in half verses using static import and alias.
>>>
>>> Also, for selective import, I think using "from" instead of "with" looks much
>>> better.
>>
>> I agree that 'from' is better than 'with', but I just don't see the advantage of
>>
>> from m2 import func,abcd,efgh;
>>
>> over the likes of
>>
>> import m2.func, m2.abcd, m2.efgh as f4;
>> import std.stdio, this.other.cool.db.lib as dblib;
>>
>> because then you get the aliasing in there as well. True, there's a little redundant typing of 'm2'.
> 
> If 'm2' is actually 'some.guys.super.cool.library.module' then the redundant typing adds up.

But then you could alias some.guys.super.cool.library.module, er,  no wait... <g>

Seriously, you're spot on - I didn't consider that.

> 
>> Also,
>>
>> from m2 private import func,abcd,efgh;
>>
>> or
>>
>> private from m2 import func,abcd,efgh;
>>
>> sucks IMO.
> 
> I don't really mind the former, and I wouldn't terribly mind the latter if expressed differently:
> 
> private
> {
>     from m2 import func, abcd, efgh;
> }
> 
> Though I think the real utility with the from/with syntax is that it would allow for selective public exposure of symbols to importing modules.
> 
> 
> Sean

John Reimer wrote:
> An excellent post.  I feel much the same as Sean about the reason it is so
> difficult to "convince" in relation to the import syntax issue.  It is about
> aesthetics to a great extent.  But I think the aesthetics are very important in
> this situation because it decides how D appears to those trying to understand
> the language.
> 
> I aslo share Seans feelings concerning the alias attribute.  "alias" is a great
> addition to the D langauge.  Perhaps I was unclear in my last response to
> Walter: alias, in itself, is not a hack in the general case.  But I believe it
> is laborious and ugly when used in the context of modules and imports.
> 
> D should be elegant.  Using alias and static import comes across as a verbose
> workaround when one is working with multiple module imports; in all other cases,
> it may be equivalent, but I think it's just plain ugly in comparison to the
> alternative syntax using with/as or from/as.  It accomplishes something that
> could be greatly simplified with an addition of a minor syntax expansion.
> 

Excellent summation.

> -JJR
> 
> In article <e8rk68$1fat$1@digitaldaemon.com>, Sean Kelly says...
>> 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.
>> I think Kris was merely suggesting that the need for a separate alias declaration for each import was the problem, not the idea of aliasing itself.  If a particular module imports 10 others, that's 10 separate aliases required as well, and there's no good way to write them in a way that makes for easy readability and maintenance.  This is the point he was trying to make below.
>>
> 
> <snip great post content>
> 
> 

On Sun, 9 Jul 2006 19:15:29 +0000 (UTC), John Reimer <John_member@pathlink.com> wrote:
> In article <e8rhud$1cca$1@digitaldaemon.com>, Deewiant says...
>>
>> John Reimer wrote:
>>> Also, for selective import, I think using "from" instead of "with" looks much
>>> better.
>>>
>>
>> "from" is a quite common variable name though, so introducing it as a keyword
>> would probably break a lot of code.
>>
>
>
> It is?  I don't see "from" very often.  Seems like an unusual name for a
> variable.  Saying it will break "a lot" of code seems like an exaggeration.

You don't write a mail server ;)

Regan

Dave wrote:
> Sean Kelly wrote:
>> Dave wrote:
>>>
>>> I agree that 'from' is better than 'with', but I just don't see the advantage of
>>>
>>> from m2 import func,abcd,efgh;
>>>
>>> over the likes of
>>>
>>> import m2.func, m2.abcd, m2.efgh as f4;
>>> import std.stdio, this.other.cool.db.lib as dblib;
>>>
>>> because then you get the aliasing in there as well. True, there's a little redundant typing of 'm2'.
>>
>> If 'm2' is actually 'some.guys.super.cool.library.module' then the redundant typing adds up.
> 
> But then you could alias some.guys.super.cool.library.module, er,  no wait... <g>
> 
> Seriously, you're spot on - I didn't consider that.
> 

Actually, how about:

import from some.long.modid func as f1, abcd, efgh as zzz;
private import from this.other.cool.db.lib as dblib;

Is more consistent w/ current syntax, maintains the visual continuity, allows more than one symbol import per module (w/o retyping the module), and combines the import w/ the alias if desired.

- Dave

On Mon, 10 Jul 2006 08:43:17 +1000, Regan Heath <regan@netwin.co.nz> wrote:

> On Sun, 9 Jul 2006 19:15:29 +0000 (UTC), John Reimer <John_member@pathlink.com> wrote:
>> In article <e8rhud$1cca$1@digitaldaemon.com>, Deewiant says...
>>>
>>> John Reimer wrote:
>>>> Also, for selective import, I think using "from" instead of "with" looks much
>>>> better.
>>>>
>>>
>>> "from" is a quite common variable name though, so introducing it as a keyword
>>> would probably break a lot of code.
>>>
>>
>>
>> It is?  I don't see "from" very often.  Seems like an unusual name for a
>> variable.  Saying it will break "a lot" of code seems like an exaggeration.
>
> You don't write a mail server ;)

I don't use multi-character identifier names that don't have at least one uppercase character. ;)


-- 
Derek Parnell
Melbourne, Australia