Make imports private by default

Hasan Aljudy hasan.aljudy at gmail.com
Thu Apr 13 06:05:09 PDT 2006


Don Clugston wrote:
> Hasan Aljudy wrote:
> 
>> Frank Benoit wrote:
>>
>>> There was a posting of Tyro
>>> http://www.digitalmars.com/d/archives/digitalmars/D/11081.html
>>>
>>> Most ppl seconded that.
>>>
>>> The problem is, that D does not work if you use non-private imports all
>>> the time. Suddenly there are conflicts.
>>>
>>> A public import make the imported module part of this modules interface.
>>> This can (and should) be made public explicitely.
>>>
>>
>> I never understood why people use private imports .. just what the 
>> hell is the point?
>> Please give real, concrete examples, not just theories/talk.
>> "Clogging up the namespace" doesn't say anything meaningful to me.
> 
> 
> If module foo publicly imports std.date, then any module which imports 
> foo cannot use std.string.format without colliding with std.date.format.
> This has bitten me several times already.

OK, this seems to be a valid problem, however, even if imports become 
private by default, there's nothing stopping foo from publicly importing 
std.date and std.string at the same time.

I think what you really want, is to import foo in such a way that you 
don't import what foo imports, not even what foo publicly imports.

So, it's better to have another kind of import .. an import that only 
imports things directly defined in module foo.

shallow import foo;

OR

direct import foo;

or something like that ..



More information about the Digitalmars-d mailing list