Make imports private by default

Don Clugston dac at nospam.com.au
Thu Apr 13 10:20:52 PDT 2006


Bruno Medeiros 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.
>>
> 
> Totally agree.
> 
> As for the consistency issue, it was said private imports by default 
> where worth the small inconsistency (of everything else being public). 
> Actually I disagree with that at the premise level: I don't think it 
> would be an inconsistency at all. Imports are not members of the module, 
> as they do not even define a new entity. They are not a "part of" the 
> module, they are more like a characteristic of it.
> Further indication is that there is no "package import". And even 
> "public import", would it be of any significant use?

Definitely. Think of the windows API, where windows.d imports dozens of 
modules. It would be very inconvenient to have to list every module you 
were using (and you'd have to know where they are).

A public import of module dog into module bird adds the public members 
of 'dog' to the interface of 'bird'. It's very rare that this is what 
you want, but it certainly occurs.
I think one way in which it's fundamentally different to classes is that 
it's natural to have a 'web' of dependencies between modules. It's 
plausible that importing a single file could clandestinely import a 
hundred others.

> (Of course one could think of imports as the definition of a set of 
> aliases, but really, I would think that's an unadequate and contrived 
> conceptualization)




More information about the Digitalmars-d mailing list