D modules/sourcecode organisation/filesystem mapping

FunkyM FunkyM_member at pathlink.com
Thu May 11 00:01:09 PDT 2006


In article <e3tsie$2adt$1 at digitaldaemon.com>, Carlos Santander says...
>
>FunkyM escribió:
>> 
>> Introduce/change rules:
>> 
>> 1) Remove the limitation that a packagename can not be a modulename
>> 2) Change definition of "module" keyword to "defines the package of the current
>> module"
>> 3) The import statement qualified name maps to the filesystem
>> packages.modulename
>> (4) Optionally rename/change to a better keyword used in this context?)
>> 
>
>Maybe it's because I'm already used to how D works, but I find these new rules a 
>bit confusing. Perhaps in time (more posts about it, refining the idea, etc.) 
>they'll become a bit clearer.
>

Yeah, infact it is a basic change mainly on the "module" keyword. My "extended"
explaination might be a bit too much information on one shot.

Right now you for a file "/foo/bar.d" you would have to write "module foo.bar;"
and you can NOT have a file "/foo.d" with "module foo;".

These changes make it possible to say "module foo;" in "/foo/bar.d" and use
"/foo.d" with "module foo;" which results in "merging" the two scopes.

Nothing changes regarding how "import" works, basicly ignore 3) if you want and
4) relates to the "module" keyword.

>> This seems to pass logic and should be possible to implement
>> (as it seems to be indirectly supported already):
>> 
>> /gtk.d:
>> module gtk;
>> 
>> enum edges { LEFT, RIGHT, TOP, BOTTOM }
>> ...
>> 
>> /gtk/window.d:
>> module gtk;
>> 
>> class Window {
>> ...
>> 
>> mainapp.d:
>> 
>> import gtk;
>> import gtk.window; // Get's ./gtk/window.d and maps it into package gtk
>> ...
>> 
>> 
>
>I think this would be tricky for the compiler. The compiler would know that 
>/gtk/window.d is gtk.window, but how would it know if /gtk.d is just gtk or 
>gtk.gtk? Remember that it's an important decision because of name mangling.

import gtk;      -> ./gtk.d
import gtk.gtk   -> ./gtk/gtk.d

There is no change in the import loading behaviour due to my proposal.
However, I wonder why already two people have "misinterpreted" it.

Infact, it's not tricky, it is the already used mechanism.

>
>> 
>> --- Martin Szulecki
>
>Like I said, maybe it's because I'm already used to how D works or maybe I 
>haven't worked in projects that large, but I haven't found the current module 
>system limiting. I think the worst thing about it is when you import two modules 
>which have the same function defined and then the compiler complains about which 
>one you want to call, and that's not even a problem of modules but of D rules 
>about resolving names. And anyway, it's not that difficult to write a couple of 
>aliases to get around it.
>

As I noted, for some people those limitations won't be the "rock in the eye" and
they will still be able to create projects as they like (build their games etc.)
with how D is working now. However, there will be a point in mid-/long-term that
will heavily define D's future upon this issue and for me it is already one.

It might take experience in the "other" languages C++/Java/C#/(any other high
level OOPL) and maybe some farsight to draw the lines. I guess it will only be
instantly obvious for people who stumbled among the same limitations when coming
from pure D. (and totally not seen as required from C purists ;)

Conflicts are not different in my approach as they are now. You can't have two
functions/classes/(elements) at the same scope.

Aliases "hacking" along with the "all.d" hack have been proposed to me.
I think one goal of D  which sets it apart from other languages is to not
require such hacks and work intuitive and practical. The alias "trick" didn't
work in this case as the compiler does break out on compilation. It seems like
unable to alias longer fully qualified names correctly.

Anyways, that would not solve the issues I listed either and add more ambigious
overhead.

--- Martin Szulecki



More information about the Digitalmars-d mailing list