D modules/sourcecode organisation/filesystem mapping

FunkyM FunkyM_member at pathlink.com
Fri May 12 05:38:51 PDT 2006


In article <e3vc41$1b5g$1 at digitaldaemon.com>, Carlos Santander says...
>
>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)

I still have trouble to fully understand why you check gtk vs gtk.gtk.
Assuming you try to point out a possible problem when multiple package levels
have the same name, after having name mangling applied.

The compiler generates (I made a simple test to verify) the one dependent on
your qualification like this:

/gtk.d        -> _D3gtk5fooi
/gtk/gtk.d    -> _D3gtk3gtk5fooi
/gtk/window.d -> _D3gtk5fooi (since the file used "module gtk;")

That does not look problematic to me regarding locating which member belongs to
which package? (Did I overlooked something?)

Now I think all the implementation seems more and more trivial and somehow
reflects the "already indirectly supported" stuff showing up.

--- Martin Szulecki



More information about the Digitalmars-d mailing list