> On Wed, Nov 26, 2008 at 8:42 PM, Ramon Leon 
> <ramon.leon at allresnet.com> wrote:
> >> 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.
> 
> Then you don't seem to realize that we work with classes and their
> code, not objects. It's code dependencies that translate into
> maintenance. As for objects, their composition from class blueprints
> is not necessarily as unambiguous as you are used to. In Newspeak, for
> example, you can't always point and say, "this will be the superclass
> of this guy" because the superclass is late-bound. You can't even
> compile that sort of thing easily unless you take messages further, to
> communicate within objects as well as between them. I view that
> information hiding as beneficial enough to even overlook the sacrifice
> encapsulation in its naive understanding (see below what I really
> think about access modifiers).
> 
> Encapsulation is an interesting thing in that popular literature
> promotes a very narrow view of it. It often starts with a reasonable
> explanation of information hiding as a noble architectural principle,
> then degrades into "so in a nutshell, store your data in private
> fields". That confuses information hiding with security. Information
> hiding helps structure code, security when it's inappropriate only
> gets in the way. There are languages where all object slots are
> accessible--CLOS, for example. I'd like to hear a C++ programmer
> declare CLOS a non-OO language because it lacks "encapsulation".
> 
> This narrow view is the evidence of how little the mainstream gets OO.
> The mechanism for encapsulation in its true sense is so ingrained in
> Smalltalk you can't take it out--it's messages, with the late binding
> of a name to its interpretation. There is no other way to communicate
> with an object. Too bad for C++, but that is what OO is about, not
> "encapsulation, inheritance, polymorphism". Message-based computation
> enables information hiding and promotes weaker code dependencies.
> 
> And now I can admit that I view access modifiers for slot accessor
> messages as more of a political tool to shut up those who would cry
> "aha, no encapsulation!" as soon as they saw messages used for slot
> access. I don't think they are an important safeguard preventing
> horrors from happening.
> 
> Here is what I find interesting about the belief that encapsulation is
> critically flawed without object data hidden away. There is enough
> Smalltalk code out there written in variable-exposing style. Large
> complex systems have been built in CLOS with its wide open object
> slots. Where are the real horror stories about this practice? I mean
> real horror--not "I remember there was this bug once..." but rather
> "...and man, we had to spend weeks fixing that crap before it started
> working".
> 
> All you hear are speculations how exposed variables are bad because
> encapsulation is good. That sounds to me like "dynamic typing is
> dangerous because you get runtime errors, and static typing would
> catch at least some of those". An intellectual bogeyman. It may sound
> reasonable as an isolated statement, but anyone with some practical
> experience will know better. Having open slots at your disposal is one
> thing, using that access indiscriminately to hurt yourself is a
> completely different one.
> 
> One last point, the most likely reason instance variables are the way
> they are is because it was a necessary performance compromise for the
> '70s hardware. No reason to consider that as some sort of heavenly
> harmony, even if you are used to it.
> 
> Cheers,
> 
> --Vassili

Definitely some food for thought.

Ramon Leon
http://onsmalltalk.com