imports - 2 years later

[Jari-Matti Mäkelä]

bobef wrote:
> I had the same problem. Removing std.something from one of the modules
> where it wasn't used at all fixed the problem...

Ok, this is currently a working workaround - but it isn't a valid
solution. Try to create a huge framework with 100+ modules and then draw
a module dependency graph on a paper. You'll see that it becomes almost
impossible to find out, which module you "should" import to avoid these
conflicts.

This might not be a problem if you write your code (one module at a
time) without any previously generated UML graphs, but in a corporate
environment this behavior forces you to test your code every once in a
while since it's completely possible that a code generator is used to
generate the module&class signatures. Currently D modules don't scale
very well here. IMHO that's not a practical solution (Walter - hint,
hint <g>).


> 
> Ant wrote:
>> Walter, we still have:
>>
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>> gtk/TextBuffer.d(88): import gtk.TextBuffer.std conflicts with
>> gtk.TextChildAnchor.std at gtk/TextChildAnchor.d(46)
>>
>>
>> these are both private import std.string;
>>
>> the interesting thing is that I had a
>> private import std.c.stdio;
>> in one module that would supply std.string to a bunch of other modules
>>
>> well, I know you cannot do anything about this
>> and I know I cannot reduce this problem... but it's better than 2 year
>> ago! :)
>>
>> Ant