|
 |
Darren New <dne### [at] san rrcom> wrote:
> CLOS doesn't do this, because people who use LISP are usually pretty good
> programmers.
No. Crappy programmers (self-taught "hackers") want everything exposed and
can't understand the reasoning behind data hiding. Good programmers understand
this reasoning and for that reason use data hiding and abstraction.
> > If the
> > internal structure of the object is exposed to the outside, you lose most
> > of the benefits of modularity.
> Like, in unsafe languages, where a stray pointer can change private
> variables without going thru the class methods? :-)
No. The reasoning behind data hiding in modular thinking is completely
independent of the language used. It has to do with program design.
If you expose the internal structure of a module to the outside, then
there's a big chance that outside will start making *assumptions* about
this internal structure. As an example, a module describing the concept
of a "color" might have four integral variables as members, one for each
color component. If this fact is exposed to the outside, then there's a
big chance that some code somewhere will assume that the "color" module
has four integral member variables with certain names.
If this happens, then you can't change the internal implementation of
this module without breaking existing code. For example, if you wanted
to change the color components to floats, or you would want to pack the
color components into one single integral value, you will most probably
break existing code (especially probable in the latter case, as the
amount and names of the member variables will change drastically).
If you can design the absolutely perfect module which will never change
its contents and will suffice for years to come, then by all means make
all members public. Us mortals will try smarter techniques.
> C# and Java both have reflection that let you get to private members from
> outside.
Thus it's one reason why the design of these languages is badly broken.
> C++ not only lets you return pointers to private members
Only if the class itself explicitly does so. You can't get to the private
members *from the outside*. (Well, at least not without some serious
hacking.)
It's usually considered bad design in C++ to return pointers to members.
> Now, ya see, I see the point of modularity is to let me reason about the
> code. If I have a private integer X, and the only things I set it to are 0,
> 1, or 2, then I should be able to have a switch with those three cases and
> never miss one. Or, for a better example, if I have a buffer, and my class
> is the only thing that writes to the buffer, I can ensure I never have a
> buffer overflow. This isn't the case in C++ any more than it is in LISP or
> Python. The only difference is, in LISP it's much harder to break by
> accident. I don't see the advantage of making variables private if the
> privacy isn't enforced well enough to give me more guarantees about the
> program's execution. It's like having type declarations that aren't checked
> at compile time or runtime - what's the point?
I don't understand what you are saying. If a class in C++ does not expose
a member array, then you can't get to that member array from the outside,
and if the class' own functions are properly designed, no buffer overflow
is possible (precisely because you *can't* access the array from the
outside).
> What do *you* think modularity is good for, that simply saying "stuff that
> starts with an underline is private to the class" isn't adequate? I'm
> seriously asking, because I'm wondering if I'm missing something.
You might be able to control your *own* code from not misusing public
variables (and you might never make mistakes), but it's more difficult to
control someone else.
If you need to tell someone else "don't access member variables whose
name start with an underscore", that's just plain stupid. You should be
able to tell that by making the *compiler* enforce it.
--
- Warp
Post a reply to this message
|
|
