Evilness object oriented approach in Morph
jmvsqueak at uolsinectis.com.ar
Thu Jan 26 01:30:07 UTC 2006
I don't like general recipes on how to design and code. If something "must
always be done this way" then it's redundant. It would be better to find a
way for not needing to write it.
If some time after you wrote a class (or a hierarchy), you need to change
the use of an instance variable to something else, you are actually
redesigning it. At that moment, you understand why accessing that ivar
directly was a bad idea, and you understand your new needs. Therefore,
that's a good time to think about the meaning of that value, and find a
Using accessors from the begining, "just in case", means losing the
oportunity to think about what you really need, and express that cleanly in
I don't think you need an excuse for not using accessors. I think you need a
reason to actually use them. Most instance variables do not need accessors
and they shouldn't exist.
BTW, if a class (or hierachy) needs to "hide" something from itself, maybe
it'ss a sign that it's getting too big, and it could be broken in
Anyway, coding in Smalltalk is a lot about aesthetics and not that much
about rational arguments. So it's ok to have different taste.
----- Original Message -----
From: "Hilaire Fernandes" <hilaire at ext.cri74.org>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, January 25, 2006 4:44 AM
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?
> 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.
>> 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?
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition.
>>> Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date:
> ADD R0,R1,R2,LSL #2
> 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
More information about the Squeak-dev