> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Michael Rueger
> Sent: Monday, January 23, 2006 2:52 AM
> To: The general-purpose Squeak developers list
> Subject: Re: Evilness object oriented approach in Morph
> 
> Hilaire Fernandes wrote:
> 
> >>I hear this argument over and over again, but I tend to disagree about
> >>its "evilness". After all, OO is all about *encapsulation* therefore you
> >>shouldn't really care about whether a class accesses its *own* iVars via
> >>messages or directly. It is only when subclassing comes into play that
> >>this causes problems, and perhaps, just perhaps, subclassing is at the
> >>root of that evilness? After all it's the subclasses that try to
> >>"extend" (some might say "violate") the well-defined behavior of its
> >>superclass.
> >
> >
> > Yes, you are right this cause trouble only when I need to extend some of
> > the behavior of some attributes. For example, I need a polygon border to
> > behvave a bit differently depending on the context of the application.
> > But as usual there are workaround and different way to do one think.
> 
> I actually disagree. Encapsulation to me also means that you shouldn't
> know if a value is in an iVar or computed. Refactoring to change the use
> from an iVar to something computed or delegated is a hell of a lot
> easier when using message sends. And the almost done jitter will inline
> the return inst vars anyway, won't it? ;-)

I disagree. :-) In the abstract sense one should not care if you are
accessing a state variable or a computed value. However, when you are
maintaining or reading code you have to know what is going on. In my
experience accessors slows down reading because you cannot assume every
message send that looks like an accessor is an accessor. This is not
too much of a problem for a class that has only a couple of ivars but
is a pain for classes that have several and some that are similar.
When you are reading a method and it uses direct ivar reference you
know without going further what it is doing.

If it is difficult to refactor from an ivar to a message send then the
tools need to be fixed. The same logic goes for using accessors because
it simpifies debugging. Make the tools serve you instead of the reverse.

> Michael