Need feedback on simple idea
eoca at afip.gov.ar
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 t-link.de]
> 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 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
> 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