Walter Bright wrote:
> xs0 wrote:
>> OT: if you'll be changing the import system, _PLEASE_ make private imports the default.
> 
> It's too late for that, sorry. Also, everything else in D is public by default, and consistency is sometimes better than special case rules, even if those special case rules make some things easier.

I'd have to agree with Walter. However, making "static" import the default might be a good compromise?

L.

Walter Bright wrote:
> Dave wrote:
>> Walter, I think what most are getting at here is that the 'as' syntax just seems cleaner and more efficient from a coding and maintenance POV.
>>
>> If it's easy to implement, then I say go for it. If nothing else, people can still use 'explicit' aliasing. I argue that 'as' will actually be quicker for newbies to grasp (*especially* when they see it in example code), and my sense is that it will be a boon to maintenance because it generally won't end-up buried in the middle of a module like many aliases would be. It's not like alias will be a wasted feature - most prominently it will be used for storage types; it just feels more 'natural' that way.
> 
> I think you're saying that this is not a discussion about functionality, but about aesthetics. I agree with that.
> 
> A couple of people have brought up the alias-in-the-middle thing:
> 
> 1) If it's in the middle because it's in a nested scope, then it only applies for the duration of that scope. Presumably, it would be easily visible to anyone looking at that scope.
> 
> 2) I think we can all agree that if it is at module scope in the middle, that is probably bad coding style - especially if there are forward references to it.
> 
> 3) The with-import-as won't eliminate bad coding style with aliases. One can still plop an alias down in the middle of the module.
> 
> 4) At least with aliases, they need to be defined within the module. This means one can do a simple search of one source file to find any aliases.
> 
> Let's look a bit at the aesthetics:
> 
>     with foo.bar import
>         abc as def,
>         ghi as jkl,
>         mno;
> 
>     import very.long.name as N;
> vs:
>     static import foo.bar;
>         alias foo.bar.abc def;
>         alias foo.bar.ghi jkl;
>         alias foo.bar.mno mno;
> 
>     import very.long.name;
>         alias very.long.name N;
> 
> 
> Yes, the latter is more typing. If one was to do this a lot, it can get annoying. But is it going to be done a lot? I think that is the crux of the matter.
> 
> P.S. There are other possible syntaxes:
> 
>     import foo.bar
>     {    def = abc,
>         jkl = ghi,
>         mno,
>     }

If we go that route, then that syntax would be fine by me as well!

I don't like starting with 'with/from' because that 'hides' 'import' or 'private import' which is what D users are used to when they scan a page for imports.

Sean Kelly wrote:
> Walter Bright wrote:
>> Dave wrote:
>>> Walter, I think what most are getting at here is that the 'as' syntax just seems cleaner and more efficient from a coding and maintenance POV.
>>>
>>> If it's easy to implement, then I say go for it. If nothing else, people can still use 'explicit' aliasing. I argue that 'as' will actually be quicker for newbies to grasp (*especially* when they see it in example code), and my sense is that it will be a boon to maintenance because it generally won't end-up buried in the middle of a module like many aliases would be. It's not like alias will be a wasted feature - most prominently it will be used for storage types; it just feels more 'natural' that way.
> 
> (I'm pretty tired so forgive me for being succinct/unclear)
> 
>> I think you're saying that this is not a discussion about functionality, but about aesthetics. I agree with that.
>>
>> A couple of people have brought up the alias-in-the-middle thing:
>>
>> 1) If it's in the middle because it's in a nested scope, then it only applies for the duration of that scope. Presumably, it would be easily visible to anyone looking at that scope.
>>
>> 2) I think we can all agree that if it is at module scope in the middle, that is probably bad coding style - especially if there are forward references to it.
> 
> Certainly.  However, it's been my experience that the vast majority of programmers on any given project tend not to be particularly scrupulous with their coding style, and code quality tends to degenerate over time.  Therefore, I believe that any means available to encourage good coding style and ease readability is worth considering quite carefully.  Having literally tossed old projects in the trash because the cost of maintenance was actually higher than a complete rewrite, I really can't stress this point enough.  But please note that I'm not suggesting a language or tool should in any way "dumb itself down" for the user, only that aesthetics plays a significant role in determining whether a particular feature or technique will be successful.
> 

Exactly - I couldn't have said it better.

>> 3) The with-import-as won't eliminate bad coding style with aliases. One can still plop an alias down in the middle of the module.
> 
> I do believe that bad code typically results from a few common causes:
> 
> * The programmer honestly doesn't know any better.  Often he's a novice or simply hasn't been exposed to the level of programming required for the task assigned.
> 
> * The programmer knows better but is in a hurry and doesn't care about cutting a few corners.  He'll go back and fix it when there's more time.  And that time will never be available.
> 

Great point.

> In both of these cases, language aesthetics makes a difference.  In the first case, a mentor could suggest an alternate approach.  For this to succeed the learning programmer must be able to remember the solution and it must be fairly easy to execute.  If not, the programmer is destined to become a member of the second category, as he now knows better but finds some excuse not to use the technique anyway, often because he can't remember the details or because it requires too much typing.  In both cases, having support for the suggested technique built into the language or tool is ideal, as it presents both a syntactical reminder and a simpler way to accomplish the task than the programmer would be inclined to use otherwise.  Finally, if the technique *looks better* than another method and it's used pervasively, it will typically be followed by others (the broken window problem).
> 

Exactly.

>> 4) At least with aliases, they need to be defined within the module. This means one can do a simple search of one source file to find any aliases.
> 
> Given the size of some of the source files I've seen, even a directed keyword search may take some time.  This simply doesn't compare to a glance at the import line.
> 
>> Let's look a bit at the aesthetics:
>>
>>     with foo.bar import
>>         abc as def,
>>         ghi as jkl,
>>         mno;
>>
>>     import very.long.name as N;
>> vs:
>>     static import foo.bar;
>>         alias foo.bar.abc def;
>>         alias foo.bar.ghi jkl;
>>         alias foo.bar.mno mno;
>>
>>     import very.long.name;
>>         alias very.long.name N;
>>
>>
>> Yes, the latter is more typing. If one was to do this a lot, it can get annoying. But is it going to be done a lot? I think that is the crux of the matter.
> 
> Assuming the language stays as-is, I believe the aliasing will likely be limited to instances where collisions occur, as the technique is easy to forget and requires a lot of typing.  I expect this will also lead to maintenance issues as library upgrades cause symbol collisions and such.
> 

Again, exactly.

> As for qualifiers themselves, I expect the typical module name to be at least two levels deep:
> 
>     import product.package.module;
> 
> and often more for large libraries.  Mango is a useful reference here, and serves to support this assertion.
> 
>> P.S. There are other possible syntaxes:
>>
>>     import foo.bar
>>     {    def = abc,
>>         jkl = ghi,
>>         mno,
>>     }
> 
> As long as the syntax is aesthetically pleasing and logically/structurally similar to Kris' proposal, I won't bicker over minutiae.  That isn't too say I'm overly fond of the syntax you just suggested, but I do understand that a slightly different syntax may parse more easily or  better fit the 'feel' of the language as a whole.
> 

The exact implementation I leave to Walter (if the statement still starts with '[private] import' ;))

> 
> Sean

Lars Ivar Igesund wrote:
> Walter Bright wrote:
> 
>> John Reimer wrote:
>>> The use of "alias" still looks like a hack.  We know you've always been
>>> firm in
>>> your belief that "alias" is the way to do it.  I doubt that all these
>>> people would be discussing options here if they were satisfied with that
>>> solution (which has been around for a looong time).
>>>
>>> We know it can be done with alias. Kris knows. We don't think it's good
>>> enough. That's why this whole topic is being wrangled.
>>>
>>> So if you choose to make the internal machinery do it with alias, fine! We just want something that's better, nicer, more professional looking!
>>> :) (please not "static import," though).
>> What I don't get is what is "unprofessional" or hackish about alias? Is
>> it (as I posted to Kris) that it looks too much like #define?
> 
> I personally don't like it myself, first of all it is not a natural word for
> me (I don't have English as my mother tongue, might very well be the
> reason), but my understanding of the word make it very unlikely to me that
> it actually _do_ something, it should just give something a different name.
> Using it for anything else (pulling something from one namespace to
> another, for instance when subclassing), or for making namespaces, is to me
> the most unintuitive thing I've ever come across in a programming language
> (I don't count COBOL here ...). I actually hate it :)
> 

Great point!! I *knew* there was something that just didn't feel right about explicitly using 'alias' for the purpose discussed here and that's it!

Lucas Goss wrote:
> Sean Kelly wrote:
>> ...
>> FQN).  And C is simply too antiquated/low-level to consider.  I'm not aware of how Java or C# operate in this context however.  I don't suppose anyone with more experience could comment?
>>
>> Sean
> 
> For C# it's FQN by default, but if you add the "using" keyword it brings it into the local namespace. If there is a collision you have to use the FQN.
> 
> Lucas

There also the 'using x = [namespace|symbol];' form, which allows you to assign a namespace _or_ a specific symbol a different name.

See: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/40005

I think they by and large got it right.

An interesting aside is that FQN's are pretty rare in C# as the amount of code to type / scan / read explodes because of the long namespace names in the .NET lib.

In article <e90enb$2cbl$1@digitaldaemon.com>, Dave says...
>
>Walter Bright wrote:
>> kris wrote:
>>> Walter Bright wrote:
>>>> 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.
>>>
>>>
>>> You've seen the requested syntax for this option, Walter. Let's revisit it again:
>>>
>>> # with m2 import func, abcd, efgh;
>> 
>> The equivalent would be:
>> 
>>     with m2 import func as f2, abcd as f3, efgh as f4;
>
>Just curious, why not:
>
>import from m2 func as f2, abcd as f3, efgh as f4;
>or
>import with m2 func as f2, abcd as f3, efgh as f4;
>
>because then it is more consistent both for D (all imports start with 'import') and in pure english language terms (starts with a verb instead of a preposition like other C-lineage languages do with their /include/import/using).

I think something like these are even better (though in the end it's going to be
an opinion thing):

import m2 = f2, abcd = f3, efgh = f4;
import m2 : f2, abcd : f3, efgh : f4;

I don't know why "as" would be used as an identifier, but D already has enough keywords! ;)

jcc7

Walter Bright wrote:
>> I think you are missing the point. *sigh*. Read above. Imports/namespaces make
>> up what constitutes a D program.  I think it's a very central, critical, and
>> special to D.
> 
> I certainly agree with that. What I am unconvinced of, however, is that the *renaming* is central or critical. Note that C, C++, Java, C#, Ruby, etc., do not support renaming. Only Python seems to. And only D has a general purpose renaming capability.

Correction: C# does support renaming, they have using-alias-directive statement which functionality-wise is pretty much like D's alias:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/vclrfcsharpspec_9_3_1.asp
This alias directive supports the aliasing of namespaces and namespace members.

But I agree that renaming doesn't seem central or critical to a D program. At least not in a way that we would need an "import ... as ..." other than just D's "alias".

Sidenote: C#'s using-namespace and using-alias do not create new members in where they are imported, they are not transitive. In other words, they are like "private import". (As everyone says D's import should be by default...)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Walter Bright wrote:
> kris wrote:
>> 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?
> 
> I did implement it according to the suggestions - and then the people who made those suggestions had issue with it. So I take issue(!) with your statement that I did it in a vacuum. I preferred the original design, and the change caused me a lot of work updating things like dmdscript which extensively used AA's.

Not to get off topic, but that was a pretty hot issue and a lot of ideas were thrown around (as with this now).  I preferred the old syntax as well but wasn't willing to press the issue and things heated up.  And by the end of the discussion I don't think there was any clear consensus on what the changes should be.  I suspect this is why everyone was a bit surprised at the changes--any changes would have been at least a bit surprising.  I think what was lacking there was public evidence of any sort of decision.  At some point things just sort of died down and the next release contained a new implementation built from the conclusions you had drawn (accurate or no).  It would have helped immensely if, before making any changes, there had been a post outlining your conclusions and the changes you intended to make.  This would inevitably have sparked more discussion, but if it's a change you don't find particularly appealing anyway, I think it's worth making sure the dissenters have no right to complain after the fact :-)

>> Anyone would think we were trying to sabotage the language,
> 
> Nobody thinks that. We are all trying to get the best design for D possible. That doesn't mean we are all going to agree on what the best design is. There's no cause to label a difference of opinion as sabotage, or any of the other epithets bandied about in this disagreement (or some of the previous ones).

I think part of the problem is that large public forums doesn't lend themselves well to directed discussion, and the general trend in d.D, simply because of the large number of participants, is that any such discussion be comes frustratingly garbled.  You don't reply to every person who feels they said something deserving a response, and people begin to feel they're being deliberately ignored.  As Kris started this discussion in the first place, I suspect it's particularly frustrating to him that it suffer the fate of all such discussions here, and that his posts are some of those not offered considered responses.  Not to mention that this is an issue he appears to have spent a tremendous amount of time thinking about, and obviously feels quite strongly about as well.

Assuming you're considering any change as a result of this conversation, perhaps the details could be settled explicitly, either here or in a separate thread?  I think everyone has said their piece at this point, and it would probably help everyone cool down a bit if things wrapped up with a suggested plan, even if the plan is to not change a thing for reasons X Y and Z.


Sean

Bruno Medeiros wrote:
> 
> Sidenote: C#'s using-namespace and using-alias do not create new members in where they are imported, they are not transitive. In other words, they are like "private import". (As everyone says D's import should be by default...)
> 

Good point.

jcc7 wrote:
> In article <e90enb$2cbl$1@digitaldaemon.com>, Dave says...
>> Walter Bright wrote:
>>> kris wrote:
>>>> Walter Bright wrote:
>>>>> 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.
>>>>
>>>> You've seen the requested syntax for this option, Walter. Let's revisit it again:
>>>>
>>>> # with m2 import func, abcd, efgh;
>>> The equivalent would be:
>>>
>>>     with m2 import func as f2, abcd as f3, efgh as f4;
>> Just curious, why not:
>>
>> import from m2 func as f2, abcd as f3, efgh as f4;
>> or
>> import with m2 func as f2, abcd as f3, efgh as f4;
>>
>> because then it is more consistent both for D (all imports start with 'import') and in pure english language terms (starts with a verb instead of a preposition like other C-lineage languages do with their /include/import/using).
>
> I think something like these are even better (though in the end it's going to be
> an opinion thing):
>
> import m2 = f2, abcd = f3, efgh = f4;
> import m2 : f2, abcd : f3, efgh : f4;
>
> I don't know why "as" would be used as an identifier, but D already has enough
> keywords! ;)
>

With one clarification:

import theAlias = theSymbol; // right associative
import theSymbol : theAlias;

or even simpler (and matching alias syntax)

import theSymbol theAlias;

Either one fine by me!

> jcc7