[squeak-dev] Re: Instance variable access in superclasses.

Vassili Bykov smalltalkbigot at gmail.com
Wed Nov 26 23:34:24 UTC 2008


On Wed, Nov 26, 2008 at 11:41 AM, Ramon Leon <ramon.leon at 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



More information about the Squeak-dev mailing list