Thoughts about modules

[Bruno Medeiros]

Derek Parnell wrote:
> On Wed, 28 Jun 2006 08:18:40 +1000, Andrei Khropov 
> <andkhropov at 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