Actually, there is a reason not to use self accessors, readability.
A method that uses direct variable access is more readable than one
that uses an accessor. If it uses an accessor you have to also read
that method because it may look like an accessor but may really do more.
I have been bitten by this.

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Hilaire Fernandes
> Sent: Wednesday, January 25, 2006 2:45 AM
> To: The general-purpose Squeak developers list
> Subject: Re: Evilness object oriented approach in Morph
> 
> Look like we have two antagonist paradigms: one for reusability (which
> is at the heart of OOP) and the other one to protect access to
> attributes (which is also at the heart of OOP).
> 
> Given the nature of Smalltalk, code reusability, I like to think the 1st
> paradigm is more important.
> 
> But beside that, there are no "rational" excuse to not use accessors
> instead of direct attribute access; otherwise why defining the
> accessors? For decoration?
> 
> Hilaire
> 
> 
> Juan Vuletich a écrit :
> > Hi Hilaire,
> > Yes, refactoring Morphic code is something to be considered.
> > But I'm not a believer of the so called "double encapsulation". If a
> > class has an accessor methods, it allows anyone to know (and enven
> > change!) the value of the instance variable. That is against
> > encapsulation. It is the object (via its class) who defines what it
> > makes public and what it keeps private. If a subclass needs to change
> > that, it's a good time for refactoring.
> > Cheers,
> > Juan Vuletich
> > ----- Original Message ----- From: "Hilaire Fernandes"
> > <hilaire at ext.cri74.org>
> > To: "Squeak Devel" <squeak-dev at lists.squeakfoundation.org>
> > Sent: Sunday, January 22, 2006 8:21 AM
> > Subject: Evilness object oriented approach in Morph
> >
> >
> >> I have realized that many of the Morph method does not use instance
> >> variable accessor but direct access to the instance variable.
> >> One may think this improve the efficiency of the method but in the
> other
> >> hand its downgrade (or just break) the oriented object efficiency of
> >> thus objets.
> >> Is refactoring the code of the Moprh methods something to be
> considered?
> >>
> >> Hilaire
> >>
> >>
> >>
> >> --
> >> No virus found in this incoming message.
> >> Checked by AVG Free Edition.
> >> Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date:
> >> 1/19/2006
> >>
> >>
> >
> >
> 
> 
> --
> ADD R0,R1,R2,LSL #2