Import concerns revisited

Brad Anderson brad at dsource.org
Wed Jul 12 12:15:28 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.

oh SWEET !!!!!

BA



More information about the Digitalmars-d mailing list