Need feedback on simple idea

Martin Wirblat sql.mawi at t-link.de
Fri Apr 11 11:46:37 UTC 2003


Maybe simple but not a good idea IMHO.

Stephane Ducasse <ducasse at iam.unibe.ch> wrote on 10.04.2003 21:36:42:
> Applicability to Squeak:
> - would break all the accessors that do something more that accessing
> (self changed) but we could use a dedicated parser/compiler so that 
> the  changes only impact a subset.

'Accessors' which do more than accessing are good programming style. 
They do what they promise to do ( morph color: Color red ). For the 
programmers mind programming is speaking a language. 

There is no disadvantage from the point of view of speaking a language 
with: 'color := x' instead of 'morph color: x' if color: is simply the 
accessor. You gain nothing here. The simplicity of which you are 
talking ( to have 1 instead of 2 methods of access ) is compared to 
the complexity of the library so minimal, that it is meaningless. 

But you loose something, namely encapsulation. Every object outside 
morph can screw the state of this morph, without doing 'more' to it, 
meaning this morph will be put in an unvalid state. 

I know there are people who believe that it is bad style to access 
inst vars directly, but I think it is the other way round. I think it 
is bad style to mix 'accessors' with 'accessors which do more' and to 
not use direct access. In such a system you don't know if you have to 
do more after sending such a message, you will have to look into the 
definition of this 'accessor'. The selector itsself is not informing 
you about what is going on. Even the existence of the method tells you 
nothing, because it has to exist. 

The conclusion for existing standard Smalltalks:

1) Whereever you can use direct access instead of sending the access-
only-message you should access directly, to make clear that there will 
be done nothing else. 

2) 'Accessors' should exist only if it is OK to use them from the 
outside. They may do more than simply access the inst var, however 
after sending them, the receiver has to be in a consistent state. So 
the existence indicates: there is nothing to do for you afterwards. 

With the idea in question

1) the accessor-selector itself will not tell you if you have to do 
something else. 

2) the accessor-method will have to exist, so you will a) weaken the 
encapsulation and b) its existence can't tell you anything. 

regards, Martin








More information about the Squeak-dev mailing list