On 26-Nov-2008, at 2:41 PM, Ramon Leon wrote:
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.
Exactly. :-)
This is even hinted at broadly in the blue book -- i.e. its not a new problem by any stretch of the imagination.
In fact I think this is where things outside the language and its implementation are more suitable to help with such problems. Eg. tools in the development environment, perhaps using structured documentation built into class definitions, might offer the necessary bridge. Perhaps something like a (pardon my association) lint-like tool for seeking out and managing inter-class dependencies and constraints (because this issue extends beyond just subclasses and superclasses and cuts across all classes which interact in any way).