D modules/sourcecode organisation/filesystem mapping

[FunkyM]

In article <16y7y27ax51ei$.fk3ned70zr4e$.dlg at 40tude.net>, Derek Parnell says...
>
>On Wed, 10 May 2006 18:53:32 +0000 (UTC), FunkyM wrote:
>> Introduce/change rules:
>> 
>> 1) Remove the limitation that a packagename can not be a modulename
>
>This is an obvious improvement because such a limitation is not intuitive
>to new comers and is a awkwardly learned one.
>

Glad to hear.

>> 2) Change definition of "module" keyword to "defines the package of the current
>> module"
>
>Are you saying then that "module xyz;" means that this file belongs to the
>package called "xyz"? This could be misleading so maybe a new keyword word
>(or the 'package' one reused) might be a better way to go.

Yes, "module foo;" says this file belongs to package "foo". I also thought about
a new/changed keyword. This relates to 4)

>> 3) The import statement qualified name maps to the filesystem
>> packages.modulename
>
>Does this mean that "import foo;" tells the compiler to get the file
>"foo.d" in the current directory, and if that fails get the file "foo.d" in
>the folder specified by the "module" keyword (xyz/foo.d in this example)?

Fortunately it's not different from how it is handled now so I could have just
skipped writing 3).

The current form is: [package|[.package|...].]module
Whereas "package" maps to directory and "module" maps to file.

"import foo;"      -> compiler gets "./foo.d" in directories of include paths.
"import foo.bar;"  -> "./foo/bar.d" in directories of include paths. 

>> (4) Optionally rename/change to a better keyword used in this context?)
>
>Better than 'module'? or better than 'import'?
>

I am referring to "module" of course regarding 2).

>> 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;
>
>Does this mean first the compiler tries "./gtk.d" and if that fails it
>tries "gtk/gtk.d" relative to each path in the -I list until it finds it?

No, it won't lookup "gtk/gtk.d" at all. It looks up "gtk.d" in "-I".

>
>> import gtk.window; // Get's ./gtk/window.d and maps it into package gtk
>
>But how do the paths in the -I list figure that algorithm?
>

This looks up "gtk/window.d" in "-I".

Note there is no change in the file loading behaviour introduced by my proposal.
"import" works as it works right now.

Only the "module" keyword's use differs which comes AFTER the "load module file"
step.

--- Martin Szulecki