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 
better solution.

Using accessors from the begining, "just in case", means losing the 
oportunity to think about what you really need, and express that cleanly in 
the code.

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

Anyway, coding in Smalltalk is a lot about aesthetics and not that much 
about rational arguments. So it's ok to have different taste.

Cheers,
Juan
----- 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?
>
> 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
>
>
>
> -- 
> 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
>
>