Import concerns revisited

Ivan Senji ivan.senji_REMOVE_ at _THIS__gmail.com
Wed Jul 12 13:12:52 PDT 2006


Walter Bright wrote:
> Don Clugston wrote:
>> Walter Bright wrote:
>>> And it's just plain irritating when writing smaller programs where 
>>> access control is quite irrelevant.
>> I agree. An interesting example is that many small classes in C++ STL 
>> programs use 'struct' instead of 'class' because it defaults to public.
>> You can find 'struct' all over the Boost libraries! Default public 
>> must be worth something.
> 
> If you write classes like:
> 
>     struct Point { int x, y; }
> 
> It's just irritating to have to write it:
> 
>     struct Point { public int x, y; }
> 
> Quite a lot of classes have all public members.
> 
>> But I don't think this argument is applicable to imports.
>> (a) For quick and dirty programs, and for most examples, you don't 
>> care if imports are public or not.
> 
> That's a good point.
> 
>> (b) Since a module exists in its own file, I don't think the 
>> consistency argument carries much weight. Functions in an executable 
>> file or DLL are only public if you add 'extern' to them (the program 
>> as a whole defaults to 'private').
> 
> Minor nit: 'export', not 'extern'.
> 
>> For modules, we're talking about 'default transitory public' which I 
>> think is quite different to 'default public'. I can see over my 
>> neighbours fence, but that doesn't mean I can see over *his* 
>> neighbours fence (even though he can).
>>
>> Changing to default private would break code, but it might not break a 
>> whole lot of existing code.
>> (a) I suspect that the majority of quick and dirty imports don't 
>> actually care if they are public or private. It's not as if every 
>> existing instance of 'import' would need to be changed to 'public 
>> import'.
>> (b) Some existing broken code would be fixed! I keep finding I need to 
>> put 'private' in front of 'import' in existing modules, to solve name 
>> conflicts.
>>
>> And any code that would break could be fixed very quickly.
>>
>> Please consider this issue again. There is still a window to change it 
>> before 1.0.
> 
> I think you've made a pretty good case for it.

Wow, this sounds very good :)



More information about the Digitalmars-d mailing list