Derek Parnell wrote:
> On Thu, 29 Jun 2006 21:09:42 -0700, Kirk McDonald wrote:
> 
> 
>>from util.str import SetEnv, GetEnv, Expand, ExpandEnvVar, ends, begins, enquote, ustrip, ustripr, IsLike, YesNo, TranslateEscapes;
> 
> 
> Unfortunately this is not completely adequate because one can't always
> import the existing name verbatim, sometimes you need an alias to
> disambiguate it. Maybe something more like ...
> 
> import from util.str SetEnv, GetEnv, Expand, ExpandEnvVar, ends, begins,      enquote, strip as ustrip, stripr as ustripr, IsLike, YesNo,
>      TranslateEscapes;

Except for the rearranging of "import" and "from", this is exactly Python's behavior.

> 
> The "from" key would tell D that only the listed names are to come into the
> namespace and all others are excluded, such that any attempt to reference
> them in the code would cause an error. The current semantics could still
> exists by not using the "from" keyword.
> 

This could work (for both "from" and "as"), though I can't help but wonder what the consequences of having a module named "from" would be. :-) (If it's not a keyword, then this must be allowed.)

import from from a, b, c as d;

> And notice the "strip as ustrip". This is because the real name is
> util.str.strip but this clashes with std.string.strip so we have to create
> an alias for one of them.
> 

-- 
Kirk McDonald

Kirk McDonald escribió:
> Kirk McDonald wrote:
>> Derek Parnell wrote:
>>
>>> On Thu, 29 Jun 2006 14:45:23 -0700, Kirk McDonald wrote:
>>>
>>>
>>>> Derek Parnell wrote:
>>>>
>>>>> Why is FQN syntax demonstrable better than the current shortcut syntax?
>>>
>>>
>>>
>>>> ...
>>>> By making it mandatory, we can always know where any name comes from, whether they are being fully-qualified, or imported on their own.
>>>>
>>>> Now, for something like writefln, which is a well-known name that everyone will recognize instantly, this is a bit of a burden. You'd have to type it a whole extra time at the top of the file! 
>>>
>>>
>>>
>>> So to summarize ...
>>>
>>> Mandatory fully qualified names makes it simple for a code reader to know
>>> in which module a member is located. But because that could be a burden to
>>> the code writer, the alias (or something similar) can be used to 'register'
>>> the FQN once in the code and allows the writer to use a short form of the
>>> name.
>>>
>>> Anyhow, I tried this coding style on Build just now and ended up with
>>> this...
>>
>>
>> [snipped some examples...]
>>
>>> import util.str;        // non-standard string routines.
>>> alias util.str.SetEnv           SetEnv;
>>> alias util.str.GetEnv           GetEnv;
>>> alias util.str.Expand           Expand;
>>> alias util.str.ExpandEnvVar     ExpandEnvVar;
>>> alias util.str.ends             ends;
>>> alias util.str.begins           begins;
>>> alias util.str.enquote          enquote;
>>> alias util.str.strip            ustrip;
>>> alias util.str.stripr           ustripr;
>>> alias util.str.IsLike           IsLike;
>>> alias util.str.YesNo            YesNo;
>>> alias util.str.TranslateEscapes TranslateEscapes;
>>
>>
>> Note that with the shortcut that Python provides, this beomes the much less redundant:
>>
>> from util.str import SetEnv, GetEnv, Expand, ExpandEnvVar, ends, begins, enquote, ustrip, ustripr, IsLike, YesNo, TranslateEscapes;
>>
>> I don't feel I could endorse this practice unless the language supports it like this.
>>
>> I don't feel this is a really serious issue. :-) "private import" provides all the sandboxing I think is needed in the absence of C++ namespaces. This is just an orginizational nicety.
> 
> While I'm proposing things, might I also propose
> 
> static import x;
> 

I like that, and it would also be backwards compatible (no changes to import)

> to mean FQN import. (This would be the same as Sjoerd's proposed "import $ : foo.bar;".) It has the advantage of looking more like D code, I think. :-) The "as" keyword is also a good idea, as in
> 
> static import x.y as z;
> 

IIRC, what was suggested long ago was to use alias, but I don't remember where alias was supposed to be:

alias import x.y z;
import alias x.y z;
import x.y alias z;

> -- 
> Kirk McDonald


-- 
Carlos Santander Bernal

Derek Parnell wrote:
> On Wed, 28 Jun 2006 08:18:40 +1000, Andrei Khropov <andkhropov@nospam_mtu-net.ru> wrote:
> 
>> Bruno Medeiros wrote:
>>
>>> I'm betting he means being able to import a module in a way that it's names
>>> (entities) are available only as fully-qualified names, and so the base names
>>> are not "imported" to the importing module namespace/scope. It's the FQN
>>> import.
>>>
>>> Andrei, (and others) if you want to check out some previous discussion on
>>> this matter:  http://www.digitalmars.com/d/archives/digitalmars/D/28423.html
>>
>> Yes, you're right.
> 
>> But anyway, as far as I can see Walter's opinion is unknown.
>>  Is he satisfied with the present situation?
> 
> I believe so.
> 
> The curent situation is a syntax shortcut. No one is prevented from using FQN syntax, and in fact I try to use that form in my code, with the main exception being 'writefln' of course ;-)
> 
> The benefit I can see from the shortcut form is that one can change modules without having to change references to members in that module, whereas with FQN usage one has to do a global find/replace over all your source code.
> 
> The cost of not using FQN though is it does not keep well over time in terms of reading the code and have an understanding of it. Plus you can get caught out sometimes when introducing another import that causes name clashes.
> 
> I'm not an advocate of either style of coding and I won't dictate to others either on this matter. I have a preference, as my fellow coders also have a preference, which may be different, and I'm okay with that.
> 
> Why do you think that FQN syntax is demonstrable better than the current shortcut syntax?
> 
> --Derek Parnell
> Melbourne, Australia

First of all, I didn't mean to say that one had to strictly use just one method syntax all over the code.
For instance I think functions (or any other entity) that are used often across modules would be fine accessed by base name only (such as writefln or others, not just std lib ones)


> The benefit I can see from the shortcut form is that one can change
> modules without having to change references to members in that module,
> whereas with FQN usage one has to do a global find/replace over all your
> source code.
>

That may currently be an issue, but with a proper and complete toolchain, namely a full-featured IDE (or even a stand-alone code editing and refactoring tool), that won't be an issue at all.
And as I've stated before, I think D, as the modern, future language it aims to be, should be designed with this target usage scenario, where one has such complete toolchain. (Analogously to how certain D aspects were designed considering sufficiently advanced compiler technology, like methods being virtual by default and possible optimizations left to the compiler).

> Why do you think that FQN syntax is demonstrable better than the current
> shortcut syntax?

Like I said before, I don't think one should use just one syntax over the other in all of the program.
So then, what is the problem? Summarizing from the other thread. If I want to access a set of entities of a given module by FQN, there is no way to specify that to the module statement (or any other statement), so that the module won't import the base names (aka: "won't import the names locally"). This is a conceptual problem. So what are it's practical ramifications?

Well, one problem is if you make some sort of typo, you may erroneously access locally(by base name) an entity which should only be available by the FQN, and if there is no mismatch the compiler might not detect it. This may be a very rare occurrence, so I guess it may not have much importance.

A more significant and surely common problem is in IDE code auto-completion. Since you cannot express in the source code if your imports should be just for FQN access or not, then the local module namespace is "polluted" with the base names of the imported module's entities, thus creating a garbage of excess names when using auto-completion. An example:

---------------------------------------
module foobar;
void DoStuff() { ... }
void DoStuff2() { ... }
---------------------------------------
module whatever;
import foobar;

void DoThings() { ... }
void DoMoreThings() { ... }

int func(){
  ...
  Do| <- press key combination here for code-completion
}
---------------------------------------

In this example you want to access entities from foobar by FQN, such as
"foobar.DoStuff()" . However, the base name (DoStuff, DoStuff2, etc.) of
the entities of foobar is also made availabe in the current module scope
by the import. So when you want to use code-completion, (in this example
with the cursor right after Do where the "|" symbol is), you will be
presented the the local options (DoThings, DoMoreThings), plus DoStuff
and DoStuff2, which you do not want to be presented.
Now imagine this in a real case scenario, where modules will may have lots of names and imports..

I say this would be surely a common problem because I believe accessing module functions by FQN may be the most common scenario.
Note that there this problem doesn't quite happen with class methods, since you can't "import a class", so method names are never imported anywhere, only the class name is, if it is at the root of the module.


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

Kirk McDonald wrote:
> 
> While I'm proposing things, might I also propose
> 
> static import x;
> 
> to mean FQN import. (This would be the same as Sjoerd's proposed "import $ : foo.bar;".) It has the advantage of looking more like D code, I think. :-) The "as" keyword is also a good idea, as in
> 
> static import x.y as z;
> 
> -- 
> Kirk McDonald

I find that name crappy, there is nothing "static" about a FQN import... X-P

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

Bruno Medeiros wrote:
> Kirk McDonald wrote:
> 
>>
>> While I'm proposing things, might I also propose
>>
>> static import x;
>>
>> to mean FQN import. (This would be the same as Sjoerd's proposed "import $ : foo.bar;".) It has the advantage of looking more like D code, I think. :-) The "as" keyword is also a good idea, as in
>>
>> static import x.y as z;
>>
>> -- 
>> Kirk McDonald
> 
> 
> I find that name crappy, there is nothing "static" about a FQN import... X-P
> 

What do you think of "final import" to mean FQN import?

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

Kirk McDonald wrote:
> Bruno Medeiros wrote:
>> Kirk McDonald wrote:
>>
>>>
>>> While I'm proposing things, might I also propose
>>>
>>> static import x;
>>>
>>> to mean FQN import. (This would be the same as Sjoerd's proposed "import $ : foo.bar;".) It has the advantage of looking more like D code, I think. :-) The "as" keyword is also a good idea, as in
>>>
>>> static import x.y as z;
>>>
>>> -- 
>>> Kirk McDonald
>>
>>
>> I find that name crappy, there is nothing "static" about a FQN import... X-P
>>
> 
> What do you think of "final import" to mean FQN import?
> 

Actually, I don't agree that is best to recycle an existing keyword, I would prefer a new keyword (if the syntax were to be that way, but like I said in the OP to Derek, there many things to consider).

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

Kirk McDonald wrote:
> Sjoerd van Leent wrote:
>> The thing I'd see useful here would be:
>>
>> import fb : foo.bar;
>>
>> Indicates all methods from module "foo.bar" are in local namespace "fb"
>>
>> import $ : foo.bar;
>>
>> Would be the same as
>>
>> import foo.bar : foo.bar;
>>
>> Regards,
>> Sjoerd
> 
> It is worth reviewing the Python syntax for imports here, I think. Python uses the FQN import by default, but supports importing unqualified names as well.
> 
>...

Thanks for the info on Python. Indeed, it might be insightful to look at the naming system of other languages. Eventually (but not right now) I would to look at how it works in other OO languages that I don't know yet.  (such as Ruby for example)

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