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
|