D modules/sourcecode organisation/filesystem mapping

Carlos Santander csantander619 at gmail.com
Wed May 10 16:21:02 PDT 2006


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.

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

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

-- 
Carlos Santander Bernal



More information about the Digitalmars-d mailing list