Darren New <dne### [at] sanrrcom> wrote:
> 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.

  I have found it extremely useful. For example, my FunctionParser library
(which has got some popularity) is, basically, one class with a relatively
brief public interface.

  During its history the library has gone through two major rewrites (the
second one almost completely from scratch, reusing only some portions of
the old version), yet without breaking the public interface and hence the
programs using it. This means that programs which use the library can safely
upgrade to a newer version of the library and still work just fine.

  As you might imagine, the almost complete rewrites have also entailed an
almost complete redesign of the private parts of the class, which have
usually ended up being completely unlike the older versions. The public
interface has stayed almost completely intact (except for some additions
which don't break backwards compatibility), which means that existing
programs don't break.

  *That* is the beauty of encapsulation.

  Of course I'm sure you have some obscure name from some obscure source
for that as well, just for the sake of disagreement.

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

  Do you really think that the compiler telling you "you must not access
this member, I refuse to compile it" is not a better way to enforce
encapsulation than just some documentation that nobody is going to read
anyways? Given that it's quite easy for compilers to do that, then why not?

  If you must have "visible" members in the class declaration for technical
and/or efficiency reasons, it's better if the compiler offers a tool for
telling the user "even though you can see this you really shouldn't be
referencing it directly" rather than relying solely on a comment line.

  It also makes it clearer in inheritance what the derived class can and
shouldn't access: The base class' private part is private, but it might
offer a 'protected' part for derived classes to use. The compiler then
explicitly checks that this abstraction level is obeyed. Easier and better
than just having some comments saying "this can be be used in derived
classes but should not be accessed from the outside".

  So yes, it's much better if the compiler tells the user he is accessing
what he shouldn't.

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

  But where do you draw the line between what is and isn't encapsulation?

  Clearly, a C struct offers no encapsulation. Also, clearly, a faulty RAM
chip trashing your program's memory doesn't mean there's no encapsulation
in the programming language. However, where is the line between those two
extremes, where encapsulation becomes non-encapsulation?

  If you call a library offered by the programming language, and that
library is buggy and trashes your program's memory, does that break
encapsulation? What if the library calls a system library (such as clib)
and *that* has a bug which trashes your program's memory? Does that break
encapsulation? What if instead of a language's own library it's a third-party
library? What if the kernel has a bug which trashes your program's memory?
Where exactly lies the line between a bug which trashes the program's memory
not breaking encapsulation, and doing so? And why?

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

  Actually it doesn't. You can read the binary representation of an object
in memory, but the standard gives no guarantees as to which byte means what.
The memory layout of objects is completely implementation-defined and thus
while you can read the individual bytes of the memory location where the
object is, you cannot safely make any assumptions about their meaning. And
trying to *modify* the memory occupied by the object is outright undefined
behavior.

  The standard allows doing that even if it's undefined behavior simply
because imposing restrictions on that would mean that compilers would
have to generate significantly less efficient code even for programs
which don't even attempt doing that. Many people don't mind.

-- 
                                                          - Warp

Post a reply to this message