Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> When a bug in one part of the 
>> program can cause arbitrary changes elsewhere, that's really minor 
>> encapsulation.
> 
>   You are still confusing a runtime memory protection mechanism with the
> programming technique of data encapsulation.

We will have to agree to disagree.

>   "A bug in the program breaks encapsulation promises" doesn't imply there's
> no encapsulation. 

It implies you have very little encapsulation.

Seriously, what is the value of encapsulation if a bug can disrupt it? I've 
never found encapsulation in unsafe languages any more useful than a naming 
convention is in a safe language.

Note that's a serious question. I'm not mocking or trying to prove a point. 
I'm simply trying to figure out why you think "private:" is noticeably 
better than a naming convention or documentation.

I'm also seriously asking why you think encapsulation is at all valuable. 
What benefit does it give you in practice, that would be difficult to obtain 
just by having decent documentation?

>   You might argue that encapsulation without runtime memory protection of
> the modules is worthless (or at least less useful), but that's a different
> thing from claiming that there's *no* encapsulation.

There's very *little* encapsulation. There's attempted encapsulation. :-)

> Encapsulation is a programming technique, not a runtime mechanism. 

Right. But a programming technique that is designed to make debugging and 
understanding the interactions of parts of a program easier yet that doesn't 
  actually do so is a poor implementation, IMO.

What do you think is the benefit of encapsulation to the programming process?

>   You are still confusing runtime memory protection with the programming
> technique of encapsulation.

I'm just going by the definition you pointed me to. If you want a different 
definition, let's see it. Maybe I'll agree with it. :-)

>>> (In that way "data hiding" is perhaps slightly a misnomer, and something like
>>> "scope access restrictions" would be better.)
> 
>> Now who is changing definitions? :-)
> 
>   Suggesting a more descriptive term is not changing the definition.
> Data hiding has always been about access rights.

Yes, but we're not talking about data hiding. We're talking about 
encapsulation. I'll grant that C++ has a weak form of data hiding, yes.

>> And in Python, if a variable name starts with _ then that variable doesn't 
>> interest you. Does that mean Python has encapsulation like C++ does?
> 
>   Does the compiler give you an error if you try to access the private
> variable from the outside?

Probably not. Do you think that would make a difference?  That when you're 
typing in the name of the member variable, you don't notice it starts with 
an underscore?

>> In languages where the private variables aren't exposed at all, this 
>> question doesn't even come up.
> 
>   Where the private members are specified is inconsequential.

Well, I'll have to disagree again there. The fact that you can see them and 
access them

>> No. You're confusing data hiding with encapsulation. You've changed the 
>> subject from "encapsulation" to "data hiding", because data hiding is the 
>> *only* kind of encapsulation C++ supports.
> 
>   They are used as synonyms, and I'm not the only one to do so.

Well, I'm making a distinction. You can have one without the other. People 
make lots of mistakes by not knowing as wide a range of possibilities as 
they should, thinking that (for example) static typing means you have to 
specify the types of variables, or that object-oriented means you have 
instances of classes, or etc.

>> If you asked me if C++ supports data hiding, I would have said "Yes, poorly, 
>> because you can see what's there and have to deal with it, but the compiler 
>> enforces the private keyword."
> 
>   As I said, you could as well argue that if you look into the source code
> of a library and see the internal structure of the object, it breaks data
> hiding and thus the programming language has "poor support" for it.

Not really, because there are legal and valid ways of getting to those 
private variables in C++, guaranteed to work by the language. If the private 
variables really were private, you'd have no reason to specify how they're 
laid out in memory, since the only code that could get to them is the class 
itself.

>   Just because the programmer can see what the object is composed of doesn't
> mean there's no data hiding. Data hiding is about access rights.

OK. I disagree, but OK.

>> I told you why encapsulation is important, listing several reasons. Data 
>> hiding is just one of them.
> 
>   Your definition of encapsulation is mixed with a runtime mechanism of
> memory protection. I don't see that requirement anywhere.

There doesn't have to be any memory protection involved. Java doesn't have 
memory protection, but applets are encapsulated. Erlang doesn't have memory 
protection, but it has encapsulation.

>> You're the one that says C++ is superior to Java because of the runtime.
> 
>   I don't even understand what you mean by that, or where I have said such
> a thing. My complaints about Java are mainly based on its language features
> (such as the inability to abstract a basic type away).

You complain that everything in Java has to be allocated on the heap, for 
example. Which is purely a runtime mechanism that has little to do with the 
language. (As shown by the newer compilers that don't allocate all objects 
on the heap, yet compile standard Java, for example.)

>> Runtime encapsulation is what made Java popular in the first place. Indeed, 
>> runtime encapsulation was pretty much the entire point of Java's development.
> 
>   No, what made Java popular was garbage collection (and lacking some
> features which some people saw as "bad", such as multiple inheritance).
> Also the idea of "write once, run everywhere".

And nobody would have heard of it if it weren't for applets. Trust me on 
this one - I was there.

Anyway, Java stuff snipped, since it's irrelevant to the conversation.

>>  > It kind of implies that "your program should still run ok even if
>>> there are bugs in it".
> 
>> You know something? There's an awful lot of software that falls into this 
>> category. Know why? Because programmers aren't perfect.
> 
>   And this is related to the definition of encapsulation how?

Because if your definition only applies to bug-free software, claiming that 
your program supports it isn't a very useful property.

>   Some bugs are easier to find than others. This has what to do with the
> definition of "encapsulation"?

Because encapsulation is there to help you find bugs!  It's there to help 
you understand the program and to ensure that each piece works how it's 
supposed to in isolation. To ensure that testing one piece and seeing that 
it works means it works when combined with other pieces.

I.e., that a class is correct as implemented.

>   If there's a bug in the operating system which randomly trashes the
> memory of a program, does that mean the programming language which was
> used to create that program has no encapsulation?

No, because that's outside the scope of the programming language's definition.

C++ on the other hand guarantees that you can access stuff by indexing 
outside the defined boundaries of objects. Hence the assurance that things 
are laid out in the order you declare them, the ability to use write() to 
store data from classes into files, etc. ("Write()" still lets you write out 
a class, doesn't it?)

>   What if the runtime which executes the program has a bug which trashes
> its memory. Does that mean the programming language has no encapsulation?

No, but it means the encapsulation has failed. It also means that that 
particular interpreter does not correctly implement the encapsulation that 
the language defined.  You could say that if the JVM randomly scribbles over 
private values, then that JVM did not correctly implement Java.

But C++ defines mechanisms for violating encapsulation, both accidentally 
and on purpose.

>   If there's a faulty RAM chip in your computer which causes part of the
> program's memory to be trashed, does that mean there's no encapsulation in
> the programming language?

No, it means your computer did not correctly implement the programming language.

>   You are confusing runtime memory protection with the programming technique
> of encapsulation. They are different things.

I explained how they're not.

>> You're either trolling me, or you're a really crappy and/or inexperienced 
>> programmer if you don't understand the difference between the scale of 
>> looking for a bug in those two places.
> 
>   Some bugs are easier to find than others. This has what to do with the
> definition of "encapsulation"?

Because encapsulation is there to make finding bugs easier.

>> The whole *point* of encapsulation is 
>> not to serve as documentation as to what's public and what's private, but to 
>> limit the amount of code you have to look at to understand the behavior of a 
>> given variable.
> 
>   And you arbitrarily set the limit of what still constitutes as acceptable
> "encapsulation" and what doesn't somewhere between the program's own runtime
> and the OS.

Because the language's runtime is part of the definition of the language. 
The OS usually isn't. Sometimes it is, in which case yes, if the OS is 
specific to the language you're using, then a failure in the OS is a 
violation of encapsulation.

>> Yes! You can! That's exactly the point. You're encapsulating who can change 
>> what values, so it's easy to find.
> 
>   Well, in that case no programming language supports encapsulation, then.
> If there's a bug in the runtime which trashes your program's memory, those
> private members can be changed.

It's not a binary choice. Of course if your hardware fails and changes 
random values in your program, then there's a problem you need to track 
down. But if you can prove that no method of your class should be changing 
one of Java's private variables set in the constructor but it changes 
anyway, then you know the code that's broken isn't Java code. You know it's 
the OS, or JVM, or hardware, or something.

In contrast, C++ has well-defined mechanisms for bypassing the encapsulation 
that are used as a normal part of programming in that language.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message