On Wed, Nov 26, 2008 at 11:41 AM, Ramon Leon ramon.leon@allresnet.com wrote:
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.
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.
So you are lamenting loss of encapsulation (a restrictive feature) in the first paragraph, and decrying loss of freedom to restrictive features in the second. Come on, pick one. If you don't want the author of a class deciding how you might decide to use it, how can you put up with him deciding what instance variables are off-limits and have no public accessors?
Indeed what I had in mind were Newspeak-style access modifiers combined with message-based slot access. Their combination in fact improves encapsulation. And no, they don't lead to final classes.
Cheers,
--Vassili