> And thus the fragile superclass problem is born.
> 
> The thing is, there are two overlapping but different perspectives
> here. From an object-centric view, sure, any state or behavior is
> there in the object and where in the hierarchy it comes from is a
> minor detail.
> 
> However, as far as the code goes, we are talking about distinct chunks
> of code, potentially written, maintained and updated by different
> people. A subclass depends on the superclass in the same way that code
> using a library is a dependent of that library's API. Managing that
> dependency has maintainability repercussions, and weakening it is a
> good thing.
> 
> Cheers,
> 
> --Vassili

Not at the expense of encapsulation by forcing access to instance variables
to go through public accessors.  Protected accessors (visible only to self
and subclasses) might be a compromise but then you open up the whole can of
worms going down that path where the language starts trying to protect the
programmer from himself with all kinds of visibility options for methods and
classes.  

This leads to things like csharp and java's final/sealed classes where the
author of a class decides all future uses of the class.  I prefer a language
to enable me, not restrict me.  I don't want the author of a class deciding
for me how I might decide to use that class in the future.  If the fragile
base class problem is the price, then I'm happy to pay it.

Ramon Leon
http://onsmalltalk.com