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
means:

"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 what).

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.

Nathanael



> From: Martin Wirblat <sql.mawi at t-link.de>
> Date: Fri Apr 11, 2003  1:46:37 PM Europe/Zurich
> To: Squeak <squeak-dev at lists.squeakfoundation.org>
> Subject: Re:Need feedback on simple idea
> Reply-To: The general-purpose Squeak developers list 
> <squeak-dev at lists.squeakfoundation.org>
>
> 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