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

Greg A. Woods; Planix, Inc. woods at planix.ca
Wed Nov 26 20:42:50 UTC 2008


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).

-- 
					Greg A. Woods; Planix, Inc.
					<woods at planix.ca>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081126/e78d1ef0/PGP.pgp


More information about the Squeak-dev mailing list