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