Import concerns revisited

Dave Dave_member at pathlink.com
Wed Jul 12 18:46:29 PDT 2006


Lars Ivar Igesund wrote:
> Walter Bright wrote:
> 
>> Lars Ivar Igesund wrote:
>>> Walter Bright wrote:
>>>
>>>> Lars Ivar Igesund wrote:
>>>>> Well, who did ever say that was a good idea, everything public by
>>>>> default? ;)
>>>> I did <g>.
>>> Right :) I don't agree.
>> Let me explain why I think default public is a good idea.
>>
>> It reduces clutter in sample, example, and quick programs. Access
>> security is an advanced feature, one that's invaluable for a complex
>> project, but is just in the way for smaller ones.
>>
>> I don't mind at all when crafting a carefully designed, reusable module
>> that 'private' needs to be explicit. It helps document the intention,
>> and lends the impression that the designer did put some thought into the
>> code.
>>
>> But when writing illustrative sample code, I feel that having to add in
>> 'public's is distracting from the point (unless, of course, the point is
>> about how access control works!). I see this a lot in sample C++ code,
>> and it is distracting, to me anyway.
>>
>> And it's just plain irritating when writing smaller programs where
>> access control is quite irrelevant.
> 
> And it here I think you miss the point. When D as a language rather help in
> writing small example programs, instead of making it easy and safe to write
> large applications and libraries, how is then D supposed to take the
> ultimate step? D has so much potential for writing large, powerful
> applications and libraries, and D continously shoots it down. Illustrative
> code should show the actual features making the language good to use in
> larger projects (once they are there, they will contain much larger bodies
> of code than all the smaller ones combined), not be a goal for the language
> itself.
> 

It would take a lot of large changes to make D ill-suited to easily 
developed and concise example programs or utilities compared to any of 
its strongly type competitors. None of the recent import proposals come 
even close to doing that.

In fact, such large changes would probably do harm to both types of 
development because D as-is is almost perfect IMO. We're just trying to 
tune the import mechanism here, especially for use with the forthcoming 
huge and diverse libraries. :)



More information about the Digitalmars-d mailing list