D modules/sourcecode organisation/filesystem mapping

[Derek Parnell]

On Wed, 10 May 2006 18:53:32 +0000 (UTC), FunkyM wrote:


...

> 
> In affect, the D programming language seems as a good candidate to challenge the
> upper mainstream competitiors

Yep, no argument there.

...

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

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

> 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)?

> (4) Optionally rename/change to a better keyword used in this context?)

Better than 'module'? or better than 'import'?

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

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


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
11/05/2006 10:01:45 AM