Re: Getting Current Working Directory

Peter Gummer wrote:
>>From: Eric Bezault <ericb-D6Qt/9opevxWk0Htik3J/[email protected]>
>>No, don't try that. {KL_OPERATING_SYSTEM}.current_working_directory
>>is not exported because it's used for implementation purposes...
>>
>>Yes Peter, I know, this should be documented somewhere so that
>>newbies don't waste their time trying to figure out what to do
>>in order to get the current working directory... ;-)
> 
> Actually, Eric, this is an interesting case.
> 
> Under the influence of OOSC2 five years ago, I took the radical step of 
> never declaring my Delphi class features 'private'. I had already suffered 
> often from being unable to access an ancestor class's privates, resorting to 
> nasty hacks in order to make my class work. (In one case, I had to copy and 
> paste hundred of lines of code from the ancestor class.) Henceforth, every 
> feature of every class I wrote was 'protected' or 'public'. To my great 
> surprise and delight, it worked beautifully.
> 
> But then, two years ago, I was working in C# with people who were convinced 
> that implementation features should be inaccessible to descendants. They 
> argued that:
> (a) 'private' makes it easier for them to change or remove these 
> implementation features, without concerning themselves that someone may have 
> written a descendant that uses them;
> (b) because 'private' reduces the number of features visible to decendant 
> classes, it helps writers of descendant classes learn which features they 
> should to call or redefine.
> 
> This reasoning is contrary to the open-closed principle, so I argued 
> argainst it, unsuccessfully. I consulted OOSC2 to refute these arguments, 
> but I only found an assertion that the literature contains no clear adivce 
> on when to use 'private'.
> 
> It's interesting to see the issue arising in the context of an Eiffel 
> library.

I think that there is a difference between writing a descendant
of class (say MY_OPERATING_SYSTEM) and hence have access to the
implementation of the parent class, and inheriting from a class
just to have access to a feature which is part of its implementation
and is otherwise not publicly available. Especially when the
functionality is actually publicly provided by another class.
Performing this kind of inheritance is a misuse of the open-closed
principle in my opinion.

-- 
Eric Bezault
mailto:ericb-D6Qt/9opevxWk0Htik3J/[email protected]
http://www.gobosoft.com



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/saFolB/TM
--------------------------------------------------------------------~-> 

To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected] 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/gobo-eiffel/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/