Nathanael Schärli wrote:

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

[lot's of good stuff snipped]

I totally agree with Nathanael's comments...looking at instance 
varaibles as if they were somehow untouchable or private is the wrong 
way of looking at it.  It's very similar to the argument in favor of 
having public/protected/private methods.  First, you can always get an 
an object's inst vars using #instVarAt:(put:)...so any argument that 
there is encapsulation is wrong.  There isn't.  There's just some notion 
that gives the user of the class some idea of what's safe and what's not 
safe to do.  I tend to view the notion of public/protected/private 
methods as a feeble attempt at classifying methods based on how likely 
it is that their interface will change over time (private being the most 
likely, public being the least).  Similarly, an instance variable 
without direct getters/setters is simply a comment saying "don't 
directly get or set this inst var, or if you do, then be prepared to 
accept the consequences when I release my next version." 

Encapsulation is really only achieved by responsible usage of the 
interfaces exposed by a class. 

So, to say that you're losing encapsulation is simply not accurate.  You 
might be loosing some interface notational capability, but you are not 
losing encapsulation because you cannot lose what you never had in the 
first place.

- Stephen