Right on! Thanks for putting it so clearly.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Nathanael Schärli
> Sent: Friday, April 11, 2003 7:30 PM
> To: 'The general-purpose Squeak developers list'
> Subject: RE: Need feedback on simple idea
> 
> 
> 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
> 
>