Warp wrote:
>   I started by defending data hiding principle in the object-oriented/modular
> programming paradigm, and stressed that this principle is completely
> independent of the language used.

We did kind of get into a bit of a flurry of messages there, didn't we?

Let's see. I think we started out with a comment that minimalist languages 
with powerful syntax (e.g., LISP) can implement things like OO without 
having it built in, by using closures for example. Then the subject of CLOS 
came up (which AFAIK doesn't use closures), with an indication that it's 
possible to access the private members with sufficient work.


You said
"""
   I think that the typical impossibility or difficulty in data hiding in
languages which do not have specific support for modularity is a sign that
the "OOP" is, after all, just a kludge.
"""
and later talked about how reflection makes it impossible to hide private 
variables and implying that clear and unambiguous naming conventions that 
everyone who codes in the language understands aren't sufficient.



I have agreed with that.  I think what we're disagreeing with is the degree 
to which the language implementation needs to enforce that modularity 
strictly, but if it does, that's better than a language that disallows it 
without enforcing it, because you can look at your code and see what it's doing.

I prefer being able to break the modularity with reflection, because it 
gives you lots of power you otherwise need to write a bunch of boilerplate 
to handle.

Lacking that, I prefer to have the modularity enforced, so I can reason 
logically about a piece of code and determine that it will work correctly 
even if there are bugs in other parts of code. I've had too many occasions 
where I spend days looking for bugs in my code only to find that someone 
else had scribbled over memory.  Or even, in one case, had printed up "now 
invoking Darren's code"[1] and then crashing out while prepping the 
arguments to my module.

Lacking that, you have glorified assembly language. :-) The machine 
represented to your code matches the machine it's running on. There are 
times when that's good, but my work lately has not been one of those times.

>   Your argument against this technique seems to be "since you can't completely
> guard against it in C++, it's as good as not having data hiding at all". As
> if C++ had anything to do with this issue.

There were examples given as "private". I don't know who started it, maybe 
not you. I was simply pointing out that it's as easy for someone to violate 
your encapsulation in C++ as in LISP because the compiler doesn't enforce 
encapsulation. You can't completely guard against it in C++, and you can't 
completely guard against it in CLOS (the LISP OO system under consideration) 
or Python. I don't see that big a difference, really.

>> Um, no, really, you can't. How do you prevent me from corrupting your 
>> private variables with a wild pointer?
> 
>   If you write standard-conforming C++, you won't have a wild pointer
> (unless you have a bug, of course).

No. If *everyone* writes standard-conforming C++, you won't have a wild 
pointer. In safe languages, it doesn't matter what you write, *I* can count 
on my library behaving as I wrote it. And, unfortunately, the C++ compiler 
may try to enforce "private", but it doesn't try to enforce 
standard-conforming C++.

If you call "accessing someone else's private variables on purpose" a bug, 
then you can't have standard-conforming Python that violates encapsulation 
without a bug, either.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message