> So you are lamenting loss of encapsulation (a restrictive feature) in
> the first paragraph, and decrying loss of freedom to restrictive
> features in the second. Come on, pick one. 

Because I consider encapsulation something that exists between objects, not
between super and subclass.  I don't consider that a conflict, interesting
that you do.

> If you don't want the
> author of a class deciding how you might decide to use it, how can you
> put up with him deciding what instance variables are off-limits and
> have no public accessors?

Again, the object class divide; he can't, in Smalltalk, restrict me from
seeing instance variables if I subclass his class.  I like it this way.
When I'm building a new class it's up to me whether to choose to use
inheritance or not and if I choose to do so it's because I want to share
code or extend or specialize that class and I want direct access to anything
in that superclass.  My class is not his class and if I do something that
makes my classes instances misbehave that's my problem, not his.

The public interface of instances of his objects however, is his problem and
he has every right to encapsulate and protect the implementation of his
instances.  There simply is a difference, to me at least, between using
someone else's objects, and using someone else's classes as a template to
build my own objects.  I accept encapsulation as beneficial and necessary in
the former case but as harmful and restrictive in the latter.  

I base this judgment on the vocabulary I find myself muttering in each case,
usually profanity in the latter case while I hunt down source code to change
the original authors access modifiers.

> Indeed what I had in mind were Newspeak-style access modifiers
> combined with message-based slot access. Their combination in fact
> improves encapsulation. And no, they don't lead to final classes.
> 
> Cheers,
> 
> --Vassili

They certainly start down that road, final and sealed are just as much
access modifiers as public, private, or protected; however, if not applied
zealously and taken too far (i.e. final classes), I agree it's not a bad
solution.  I would prefer not to have two ways to access instances vars so
if protected accessors were the solution I'd want them to replace all direct
instance variable access, even within a single class so slots make perfect
sense.  But at this point, we're not really talking about Smalltalk any
more.

I won't pretend to be a language designer or say I know what the perfect
balance of features is, but I rather like the balance Smalltalk struck with
no access modifiers, public methods, protected instances variables, and
trust in the programmer.

Ramon Leon
http://onsmalltalk.com