Darren New <dne### [at] sanrrcom> wrote:
> """
> Under this definition, encapsulation means that the internal representation 
> of an object is generally hidden from view outside of the object's definition.
> """

> C++ fails this. Internal representation is in the header file. But that's 
> not what I'm talking about.

  "Data hiding" doesn't mean "hidden from the programmer", but "hidden from
the outside scope". In other words, code out of the scope of the class has
no direct access to the internals of the class (in other words, you get a
compiler error if you try to access).

  You could as well argue that if you had an open source library in a language
with true data hiding (by your definition of the term), it stops being data
hiding because the programmer could just look at the source code of the
library and see the internal structure of the objects. Just because the
programmer can see the internal structure of the object doesn't stop it
from being data hiding.

  The purpose of encapsulation and data hiding is not to obscure information
from the programmer, but to offer an abstraction tool for the program design.
(In that way "data hiding" is perhaps slightly a misnomer, and something like
"scope access restrictions" would be better.)

  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. Just because the class says explicitly "hey, I have
this private member" doesn't stop it from being encapsulation and data
hiding.

> """
> Typically, only the object's own methods can directly inspect or manipulate 
> its fields.
> """

> All unsafe languages fail this.  (Lots of safe languages do too, with 
> appropriate declarations of their unsafeness.)

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

  Again, data hiding is a tool offered by the language which you can use
to increase abstraction in your program. Just because the language doesn't
guarantee that modification of random memory locations using wild pointers
will always be caught doesn't make the tool nonexistent. The tool is still
there for you to use, and the compiler will enforce it as long as you write
your code as intended.

> """
> Hiding the internals of the object protects its integrity by preventing 
> users from setting the internal data of the component into an invalid or 
> inconsistent state.
> """

> Unsafe languages fail at this. Either that, or you have never ever 
> encountered a wild-pointer bug.

  A wild pointer bug is at a completely different conceptual level than
data hiding. Encapsulation exists as a tool for *programming*, not as a
tool for the runtime. If you use encapsulation as intended, and your
program is correct, then the compiler will enforce the encapsulation.

> In theory, yes, if you don't violate the language mechanisms, then C++ 
> provides encapsulation. In practice, it doesn't, because when some value in 
> your object is randomly changed by a bug in some code running in other 
> thread, you're fairly well screwed in terms of figuring out the 
> encapsulation.

  I think that your problem is that you somehow write like having bugs
in your program is some kind of valid programming technique. "Encapsulation
should be enforced even if there are bugs in your program" sounds quite
silly. It kind of implies that "your program should still run ok even if
there are bugs in it".

  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.

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

>  That is, pretty much, the difference between safe languages 
> and unsafe languages: Safe languages *enforce* encapsulation.

  No, they don't. If you make a programming error and inadvertedly make
a member public, the compiler will do squat about that.

  You are deliberately confusing a programming technique such as
encapsulation with a runtime technique such as memory protection.

-- 
                                                          - Warp

Post a reply to this message