Need feedback on simple idea

Oca Emilio eoca at
Fri Apr 11 13:25:42 UTC 2003

But 'accessors' as a term refers to methods within an object's
implementation of a protocol. That object only knows what subsets of its
methods are just 'accessors' or 'accessors which do more'. 

It is invalid and of no use that an object A refers to methods as accesors
on another object B. A should see on B just a protocol of messages with a
clear behavior and/or semantic associated. Besides how B fulfils its
protocol is B's only responsibility. 

Based on all this I humbly think the whole argument below these lines is



> -----Mensaje original-----
> De: Martin Wirblat [mailto:sql.mawi at]
> Enviado el: Viernes, 11 de Abril de 2003 08:47
> Para: Squeak
> Asunto: Re:Need feedback on simple idea
> Maybe simple but not a good idea IMHO.
> Stephane Ducasse <ducasse at> 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