D modules/sourcecode organisation/filesystem mapping

[Carlos Santander]

FunkyM escribió:
> In article <e3tsie$2adt$1 at digitaldaemon.com>, Carlos Santander says...
>> FunkyM escribió:
>>> 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.
> 

I wasn't talking about import, I was talking about mangling names in an object file.

When the compiler generates the object file, how does it know if a member 
belongs to the module gtk or gtk.gtk? Because for one module (gtk.window) you're 
prepending the package name but for the other you're not. Will it generate 
_D3gtk3fooi or _D3gtk3gtk3fooi? (those names are from memory and just examples)

-- 
Carlos Santander Bernal