=?iso-8859-1?Q?Nathanael_Sch=E4rli?= <n.schaerli at gmx.net> wrote:
	I think that the argument about "loosing encapsulation" is complete
	bogus because it has no relevance in practice. ...
	
	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.

I thought someone would come up with this one.
Without comment about Smalltalk in general,
Squeak *DOES* have the concept of encapsulating behaviour,
and I'm not talking about the "private" category but about
compiler-enforced private methods.

Of course there are other things that affect encapsulation.
Arguably, there is no encapsulation in Java:  you can make a
serialisable object, stuff anything you want into it,
write the serialisable object out to a byte stream, tamper
with the byte stream in any way you like, and read the
byte stream back.  Now you have (copies of) objects whose state
has been mutated in any way you desire.

Just because the boat is leaky doesn't mean it is ok to blow holes
in the hull with grenades.

In the same way, the imperfection of encapsulation in Smalltalk is
no reason to redesign the language so that people can no longer use
encapsulation in their designs.

There is a big difference between "using certain primitives, you can
if you try hard enough tamper with an object's state" and "because
all variables are now exposed, you can change an object's state
BY ACCIDENT".

Surely the answer is to provide _better_ encapsulation in Squeak,
not to blast away such encapsulation as we now enjoy!