Import concerns revisited

[Bruno Medeiros]

Walter Bright wrote:
> 
>> OT: if you'll be changing the import system, _PLEASE_ make private 
>> imports the default.
> 
> It's too late for that, sorry. Also, everything else in D is public by 
> default, and consistency is sometimes better than special case rules, 
> even if those special case rules make some things easier.

Nonsense, of course it's not too late! In fact, for this change in 
particular, it's quite easy to write a trivial script that can easily 
convert from one syntax to the other, without errors. So if you want to 
argue about this proposal, do so regarding it's merits only, not 
compatibility.

So about the consistency issue: I too think consistency and 
orthogonality are very important (maybe even more than you :P ), but the 
key thing to notice here is that a (private) import is not defining new 
members of a module. It's not creating a new entity or entities. I view 
an import as very different from defining a class, struct, variable, 
function, etc., and therefore I don't find it inconsistent for the 
default protection to be different.

In fact, I even have some doubts about the whole thing of imports having 
protection attributes in the first place. It wouldn't strike me as odd 
if import was protectionless, working only the same as the current 
"private import", and that the functionality of the current "public 
import" were achieved in some other way like "alias somemodule.*;" or 
"aliasimport somemodule;" or something like that.

=> One clue that an import is different from any other declarations with 
protection attributes, is that its names go to a secondary namespace. 
That's inconsistency right there. (if you view the imports the same as 
the other things)


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D