Need feedback on simple idea

Martin Wirblat sql.mawi at
Sat Apr 12 11:26:48 UTC 2003

Hi Nathanael,

You are right 'loose encapsulation' was a wrong i.e. exaggerated 
formulation. I should have used what I called it later: 'weaken 

However, what about my other argument?
Because the selectors for the accessor methods are now reserved for 
only accessing the inst var you have to choose other selectors for 
'accessing and doing more'. These choices will be done differently by 
different authors ( e.g. updateColor: setColor: ... ). In other words 
the vocabulary is widening. In my scheme the single instVarName-
selector ( like color: ) would be used. 

I know I did not say this explicitly, perhaps because I tried to 
explain my opinion on what are really two things. 

1) Partly replacing direct access with sending of accessors in todays 
code and having a mixture of pure access and doing more for 
'accessors' so that you can not guess from the selector what will 
happen and so that you don't know if you have to do something else or 

2) Your approach where there is no such mixture.

Clearly the first one is worse, but evaluating the pros as Stephane 
puts them I can't see any clear compensation for what I view as ( even 
minor ) disadvantages of 2). 

> simplicity/uniformity no distinction between state and methods

What you gain in simplicity is even smaller than what you loose in 
weakening of encapsulation. 

Not to be able to distinct between state and method can hamper the 
understanding of the nature of the object. 

regards, Martin

Nathanael Schärli <n.schaerli at> wrote on 11.04.2003 18:29:34:
>Hi Martin,
>> 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 think that the argument about "loosing encapsulation" is complete
>bogus because it has no relevance in practice. In fact, encapsulation
>"The idea of encapsulation in programming languages comes from 
>abstract data types. In this view, an object has an interface part 
>and an implementation part. The interface part is the specification 
>of the set of operations that can be performed on the object. It is 
>the only visible part of the object. The implementation part has a 
>data part and a procedural part. The data part is the representation 
>or state of the object and the procedure part describes the 
>implementation of each operation."
>Since the Smalltalk language has no concept of encapsulating 
>behavior, I really don't think that it makes much difference whether 
>you can encapsulate state or not. An average class typically has tons 
>of "private" methods that are exposed to the outside anyway, and thus,
>every outside object can (at least indirectly) screw with the state of
>such an object anyway.
>As an example, just take the class Morph you were talking about. This
>class implements 1088 methods and does not provide any operational
>encapsulation whatsoever. This means that there are tons of methods 
>that every outside object can call to screw the state of a Morph. 
>Besides methods that indirectly screw state (e.g, #moveWithPenDownBy:,
>#privateFullMOveBy:), there are ironically even methods such as
>#privateColor:, #privateBounds:, #privateOwner:, #privateSubmorphs:,
>etc. that do exactly what you say you don't like, namely directly
>exposing state. (BTW: #privateOwner: has 33 senders and many of them 
>are outside Morph).
>And Morph is not an exception. In the opposite, many other classes are
>even worse. As an example, the class OrderedCollection contains 
>methods such as #insert:before:, #removeIndex, etc. that operate 
>directly on the internal array. (This means that executing 
>"aCollection removeIndex: 3" actually removes the object at the 3th 
>position in the internal array, and not the object at the 3th 
>position of the collection!!). In addition, there are is also a 
>methods #setCollection: which again allows any outside object to 
>directly mess with the internal state. 
>Looking at Squeak you will see that:
>- Most of the classes have many "private helper methods" that allow an
>external object to screw with the state. (Just think: If you really
>program in a structured way, a Smalltalk method typically has just 
>about 5 lines, all the rest is factored out into "helper methods". 
>This means that for each of these methods you typically get a couple 
>helper methods).
>- Classes typically only have a a handful (or even less) slots. 
>Usually, the number of slots is way smaller than the number of 
>methods in the "private" protocol. (As an example, OrderedCollection 
>only has 3 slots (array, firstIndex, lastIndex) and it implements 12 
>"helper methods" that allow one to screw with these slots no mater 
>Now, please explain me why you say that it is precisely this small set
>of accessor methods that would make us "loose" encapsulation? Do you
>really think ST has encapsulation now? And let me ask you another
>question: If you care so much about encapsulation, would you then like
>to see a clean language-level encapsulation mechanism in Squeak that
>would provide _real_ encapsulation (meaning a consistent ans unifying
>encapsulation mechanism for any sort of implementation, no matter
>whether it is state or behavior)? If no, then explain me why you
>criticize getting an average of maybe 6 unencapsulated accessors per
>class if an average class maybe already has 10 of them anyway? I think
>this is quite hypocritical.
>> From: Martin Wirblat <sql.mawi at>
>> Date: Fri Apr 11, 2003  1:46:37 PM Europe/Zurich
>> To: Squeak <squeak-dev at>
>> Subject: Re:Need feedback on simple idea
>> Reply-To: The general-purpose Squeak developers list 
>> <squeak-dev at>
>> 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