Avdi Grimm
1/27/2007 7:44:00 PM
To the contrary, it's not madness at all. It's a legitimate
interpretation of OO principles to say that a private member variable
is private to a class, and should be inaccessible to all clients of
the class - INCLUDING derived classes. Because your class may be used
as a base class by other programmers in other projects, it's important
to be able to define a stable interface not only to the class's
collaborators (other classes), but to it's children as well. That way
other programmers can build on your class without worrying about the
changes in implementation.
This is precisely why both C++ and Java make a distinction between
"private" and "protected". The former is for internal use only by the
class; the latter is the interface the class exposes to it's
descendants. And public, of course, is the interface it exposes to
the outside world.
Actually, I wouldn't mind seeing this in Ruby. Ruby's approach is
very flexible and convenient, but it carries with it the danger that
if you derive from a third-party class (like, say, ActiveRecord), you
might inadvertently overwrite a member variable that the base class
uses.
--
Avdi
On 1/27/07, Phrogz <gavin@refinery.com> wrote:
> On Jan 27, 9:05 am, Richard Roberts <ricisb...@yahoo.co.uk> wrote:
> > Anyone else got views on this??
>
> It looks like Ruby 1.9 will give you the ability to define private
> methods in the base class (which may be simple getter/setter methods)
> that are accessible to the base class, but not the descendents. Of
> course the subclass will still have access to the instance variables -
> in my opinion it would be madness to have 'inheritance' without this.
>
>
>