imports - 2 years later

Jari-Matti Mäkelä jmjmak at utu.fi.invalid
Thu Mar 9 01:00:50 PST 2006


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! :)

I think the problem is that DMD tries to be more intelligent than it
really is. It saves the private symbols in the symbol table too, but is
unable to hide them, when a public one should "mask" them. Another
problem is that when the same module is imported using two different
"routes", DMD is unable to determine, whether these modules are the same
ones.



More information about the Digitalmars-d-bugs mailing list