Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> Darren New <dne### [at] sanrrcom> wrote:
>>>>> (Well, at least not without some serious hacking.)
>>>> Running off the end of an array is "serious hacking"? I wouldn't think so.
>>>   Now I'm completely puzzled. We are talking about public interfaces and
>>> private members, and you start suddenly talking running off the end of an
>>> array? I can't see *any* connection whatsoever between these two things.
> 
>> I'm saying that C++ does not enforce that you don't change private instance 
>> variables from outside the class.
> 
>   And this has exactly what to do with whether (compiler-enforced) data
> hiding is a good thing or not?

Because there's two reasons for data hiding: (1) allow more flexibility in 
implementation, (2) allow easier debugging.

If you can violate my encapsulation, I don't see the data as especially 
encapsulated, is all.

>   Every single discussion about programming with you turns into C++ bashing,
> no matter what the subject.

I'm happy to bash any other unsafe OO language you might want to name. :-)

>   Could that perhaps change 'y'? Maybe. The standard allows the compiler
> to do whatever it wants. If the compiler wants to change 'y', it has the
> standard's blessing. If the compiler gives you an error message saying that
> you are a moron, that's ok as well.

Yep. Can you name a C++ implementation that doesn't change "y" in that 
sample? I'm 100% serious here, because I know of C interpreters, but I've 
never seen a C++ interpreter. Or is there a tool that would catch that at 
runtime?  It would make some sorts of debugging a lot easier. I don't think 
purify handles that sort of thing, does it? It seems like it would be 
difficult, because the size of pointers would have to change or the shape of 
the structure would have to be incompatible with C.

>>>>  The compiler doesn't enforce the 
>>>> encapsulation in C++ - it just gives warnings when you use a variable name 
>>>> that's private.
>>>   Warnings? Trying to access a private variable gives a compiler error.
> 
>> Only if you do it in the obvious way. Or are you saying there's a 
>> compile-time warning for calling memset() with too large a size?
> 
>   I'm just baffled about how you twist words. Exactly where am I saying
> anything like that? I don't even understand how you can come with such a
> conclusion. It doesn't make any sense.

I'm used to thinking about the semantics of a program. It's easy to 
miscommunicate when the semantics of a language include "there are no 
semantics for this valid piece of code that compiles cleanly."

It's untrue that "trying to access a private variable gives a compiler 
error." It's only true if you try to access the private variable in the 
obvious way. It's not true if you explicitly or accidentally circumvent the 
runtime system.

> "The compiler doesn't enforce encapsulation, it just gives warnings."
> "Actually the compiler gives an error if you try to break encapsulation."
> "Are you saying there's a compile-time warning for calling memset wrongly?"
> "???"
> 
>   I just can't follow your logic.

I said "the compiler warns you in some cases that you're accessing private 
variables of other classes, and it doesn't warn you in other cases that 
you're accessing private variables of other classes." You want to make that 
into a discussion about whether it's a "warning" or an "error".

The compiler only gives you error messages if you break encapsulation in 
*some* ways, not in other ways.  I.e., only when you break encapsulation on 
purpose does it give you a warning. When you break encapsulation by mistake, 
it doesn't. If you access a private variable by name, it won't compile. If 
you access a private variable by address, it compiles fine.

When you break encapsulation in CLOS on purpose, you don't get a warning, 
but you know you're doing it because you're groping around in the source 
code of the class you're violating. I don't see how making that uncompilable 
can help.

Explain that to me? Really, without treating it as an attack, explain to me 
how requiring a programmer to read the source code (not header) of the 
module to discover the names of private variables isn't sufficiently 
encapsulated, compared to something enforced at compile-time but not 
runtime? It's discussions like this that lead me to a better and deeper 
understanding of the craft. :-)

>> Sure you do. You have to put "private:" in front of the private bits and 
>> "public:" in front of the public bits.
> 
>   Exactly how is that "documentation"? That's source code.

And in CLOS, it's also source code. The only way to break encapsulation is 
go read the source code to see what the private variables are. It's not 
something you do accidentally, any more than you accidentally
#define private public.

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