Derek Parnell wrote:

> 
> I'm hope I'm not messing up Kris' words here but I think he is saying that  we need to cut down on the amount of typing and reading people *must* do  in a program. Keep it to a minimum. Try and work the syntax so that the  common and mandatory things are short, easy, and intuitive to do. Make the  unusual and 'special' things have more detail in the syntax.
> 

I 100% agree.  The usual cases should be implicit, and the corner cases explicit.

I would really like private aliases in any case, Walter.

-DavidM

Walter Bright wrote:
> Ivan Senji wrote:
>> There should be a big difference (if I understand things correctly):
>> A simple example:
>>
>> If I have:
>>
>> module m1;
>>
>> int func(){return 1;}
>>
>> and
>>
>> module mainmodule;
>>
>> import m1;
>>
>> void main()
>> {
>>   writefln(func());
>>   writefln(m1.func());
>> }
>>
>> there are no problems with that!
>>
>> But if I add:
>>
>> module m2;
>>
>> int func(){return 2;}
>>
>> and change mainmodule to:
>>
>> import m1;
>> import m2;
>>
>> void main()
>> {
>>   writefln(func());     //<- conflict
>>   writefln(m1.func());
>>   writefln(m2.func());
>> }
>>
>> And suddenly I get a lot of conflicts.
> 
> I agree, but the "static import" resolves that.
> 
> 
>> Sure there is a way to solve it by adding:
>>
>> alias m1.func func;
>>
>> And then use m2.func to use func from m2.
>>
>> But what if I wanted to give m2.func a totally different name to avoid
>> confusion, i can try to add this:
>>
>> alias m2.func someOtherName; instead of alias m1.func func;
>>
>> But then once again I would get an error about a conflict:
>>
>> Once again there is a solution:
>>
>> alias m1.func func;
>> alias m2.func f2;
>>
>> And it works OK, but the intention here is a bit hidden.
>>
>> Conclusion:
>>
>> import m2.func as f2;
>>
>> is not the same as:
>>
>> import m2;
>> alias m2.func f2;
>>
>> but is equivalent to:
>>
>> import m2;
>> alias m2.func f2;
>> //insert here a possibly huge number of aliases to avoid conflicts of
>> m2.func with func from other imported modules.
> 
> If "static import" is used, there aren't any conflicts.
> 
> There are two issues here:
> 
> 1) the "second class name lookup" characteristic of import.
> 2) inserting a name from one scope into another (possibly renaming it in the process)
> 
> static import does (1) by importing but disabling the second class lookup.
> alias does (2).

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.

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

Yes, but you could also:

import m2.func as f2, m2.abcd as f3, m2.efgh as f4;

It's not hard for us to understand, I think most of us just like the syntax better and it encourages that these aliases will be kept at the 'top' of a module for easier maintenance!

> 
> You've seen the requested syntax for this option, Walter. Let's revisit it again:
> 
> # with m2 import func, abcd, efgh;
> 
> 

That doesn't address the aliasing if I'm understanding correctly (what if m3 is imported and has an 'abcd' and 'efgh' also)?

Also, I don't like the 'with' because it breaks the continuity of a page scan (for me at least). May seem silly, but I'm expecting to see lines starting with 'import' or 'private import' when I check out what people are importing.

Walter Bright wrote:
> [...]
> [...]

In reply to Walter, Kris, Derek and all who argue on the merits of "import X; alias X A;" vs "import X as A;"

Once we have FQN import, which by the looks of it we'll have pretty soon (hopefully not with the syntax "static import" though), we'll be able to do something which is the first thing I've wanted to do with a FQN import: devise a one-line macro of some sort that would FQN import all modules of a project. Fortunately, a macro of some sort won't even be necessary, we can do it with proper D. Just make a file allfqn.d with the contents:

  module allfqn;

  static import mod.foo;
  static import mod.bar;
  static import math.whatever;
  static import math.whatever2;
  static import gfx.whatever;
  static import gfx.whatever2;
  ...

then just do a regular import of all.d in other files:

  module foo;

  import allfqn;

Then the equivalent of:
  import MOD.FOO as BAR;
becomes just:
  alias MOD.FOO BAR;
instead of:
  static import MOD.FOO;
  alias MOD.FOO BAR;

thus this whole debate of one syntax being 2 times wordier than the other becomes a non-issue? It has for me, unless there is some other issue.

This behavior of having all project entities(names) automatically available by FQN is also how Java and C# work[*], which I think is a quite sensible approach. And perhaps this should even be the standard among D programs.

[*] How is it in Python and Ruby? (I do not know those languages well) Or in any other language you know with such similar structured hierarchical namespacing?


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

Walter Bright wrote:
> Bruno Medeiros wrote:
>> I must contested the proposed named by Walter. "static import" seems a pretty crappy name, there is nothing "static" about it. Do we have to recycle existing keywords? I'm not very much into this phobia of introducing new keywords. You didn't have a problem introducing "scope"... :P
> 
> Turns out, "scope" was a problem. It broke a lot of my code - a lot more than I'd anticipated.

Remember my Google SoC project proposal? Such a tool has the potencial to make such changes trivial. Just rename all names which have a name that has become incompatible(a keyword) to a new name:

  $ dtool @someproj rename *.scope scopefoo

In fact, couldn't DMD easily do something similar, as it already has a full D parser?

In any case, the good news is I will be working on such a tool, during the next school year (as my final degree project). :)

Hum, BTW, what lots of code did "scope" break? Phobos? I was under the impression you didn't have much personal code written in D.

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

Bruno Medeiros wrote:
> This behavior of having all project entities(names) automatically available by FQN is also how Java and C# work[*], which I think is a quite sensible approach. And perhaps this should even be the standard among D programs.
> 
> [*] How is it in Python and Ruby? (I do not know those languages well) Or in any other language you know with such similar structured hierarchical namespacing?
> 
> 

I've reviewed Python's import rules previously:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39396

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

Walter Bright wrote:
> Bruno Medeiros wrote:
>> Well, that clearly states that private members should not be invisible in C++, but I'm having trouble understanding why. He says "Without it, private out-of-class member declarations become impractical to parse in the general case." but I don't see how or why, anyone has an example or clarification?
> 
> I don't understand that, either.
> 
> My best guess is that getting consistent overloading results when changing protections was deemed by Bjarne to be less surprising, but I'm just guessing.

Well the "become impractical to parse in the general case" part makes me think it would be a hard-constraint: it would make something broken or unfeasible, not just strange or surprising. If you find anything let us know.
BTW, I'm only asking this out of curiosity, I don't think it has a bearing on D semantics. It seems to me it would be quite feasible for D not to consider private overloads in its name lookup. (or any other non-acessible names)

Alternatively, we could require that any name overloads have the same protection level. It doesn't seem to be a bad solution. It is considered good practice that the semantics of overloaded functions are closely related, so maybe so should the protection level be.


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

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.

-JJR

Dave wrote:
> kris wrote:
>> You've seen the requested syntax for this option, Walter. Let's revisit it again:
>>
>> # with m2 import func, abcd, efgh;
>>
>>
> 
> That doesn't address the aliasing if I'm understanding correctly (what if m3 is imported and has an 'abcd' and 'efgh' also)?


The proposed syntax for that has been noted as the following:

# with m3 import func, abcd as myabcd, efgh as myefgh;

or

# from m3 import func, abcd as myabcd, efgh as myefgh;

This align well with the non-selective import:

# import lib.text.locale as locale;


> Also, I don't like the 'with' because it breaks the continuity of a page scan (for me at least). May seem silly, but I'm expecting to see lines starting with 'import' or 'private import' when I check out what people are importing.


Yes, I agree. But feel the from/with syntax is quite suitable compared to the having a slew of alias decls polluting the import space.

Dave wrote:
> That doesn't address the aliasing if I'm understanding correctly (what if m3 is imported and has an 'abcd' and 'efgh' also)?

Dave; the other option proposed earlier (by Walter) was to extend the import syntax to hit top-level decls within a module:

# import lib.text.locale.Time;   // import Time only

Which can be extended in the following manner:

# import lib.text.locale.Time as myTime;

The potential drawback to this is that you basically get one import at a time. But that's fine if continuity is more important.

Each of these options are listed in the root of this thread-branch: "Import concerns revisited"