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