|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |