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.

  "A bug in the program breaks encapsulation promises" doesn't imply there's
no encapsulation. It only implies that there's a bug in your program which
makes it misbehave.

  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. Encapsulation is a
programming technique, not a runtime mechanism. The memory protection
encompasses a lot more than just protecting module members from being
trashed.

> > In other words, code out of the scope of the class has
> > no direct access to the internals of the class 

> And you understand why I'm disputing that this is the case, right?

> *Correct* code has no direct access to the internals of the class *by name.*

> Incorrect code has direct access to the internals of the class, and correct 
> code has direct access as long as it doesn't do so by name. (For example,
>    write(outfile, &myInstance, sizeof myInstance);

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

> > (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.

> >   In other words, if you want to keep a good abstraction level in your
> > program, if something is marked as "private" then that something doesn't
> > interest you unless you are actually implementing the class which owns
> > that private member. 

> 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?

> 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.

> >   Now you are deliberately confusing a general non-restriction of memory
> > access with the concept of data hiding.

> 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.

> 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.

  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.

> 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.

> 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). These are basically
all compile-time features.

> 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".

> > "Encapsulation
> > should be enforced even if there are bugs in your program" sounds quite
> > silly. 

> Tell that to people running Java applets in their web browser. I mean, isn't 
> that basically the difference between Java applets and ActiveX?

  Now you are confusing it with sandboxing, another memory protection
mechanism.

>  > 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?

> >   Assume that you have a bug in your program in that you forgot to write
> > "private" in conjunction with a member declaration, making it public.
> > There's a bug in your program, which made the member accessible from the
> > outside. By your definition this programming language doesn't enforce
> > encapsulation because if there are bugs in your program it may allow
> > private members to be accessible from the outside.

> Not at all. The difference is that when I go to my class where the problem 
> manifests as incorrect data in instance variables, and I look through the 
> code that references those ought-to-be-private variables and see that none 
> of them set it wrong, and then I look at the declaration and see it's 
> public, I can change that to private and see who is accessing it that 
> shouldn't.

> On the other hand, when you have a wild pointer bug overwrite my instance 
> variable, the place I have to look in the code to find that is *everywhere.* 
> Including code I don't have source for.

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

  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?

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

  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?

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

> 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"?

> 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.

> >   That's just silly. You cannot define the concept of encapsulation in
> > terms of buggy programming.

> 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.

-- 
                                                          - Warp

Post a reply to this message