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

Warp wrote:
> nemesis <nam### [at] gmailcom> wrote:
>>>   Ok, "written agreement" then, if you want to nitpick. Not much difference.
>>> Still not enforced nor sanity-checked by anyone or anything.
> 
>> Here is where Larry Wall's quote really applies. ;)
> 
>   Since when have code sanity checks become a bad thing?

When they become something to work around, rather than a help to the 
programmer. If you need to go read the source code of the module you're 
accessing to figure out how to get to the private variables, it's no longer 
a "code sanity check" IMO.

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

Darren New escreveu:
> Warp wrote:
>> nemesis <nam### [at] gmailcom> wrote:
>>>>   Ok, "written agreement" then, if you want to nitpick. Not much 
>>>> difference.
>>>> Still not enforced nor sanity-checked by anyone or anything.
>>
>>> Here is where Larry Wall's quote really applies. ;)
>>
>>   Since when have code sanity checks become a bad thing?
> 
> When they become something to work around, rather than a help to the 
> programmer. If you need to go read the source code of the module you're 
> accessing to figure out how to get to the private variables, it's no 
> longer a "code sanity check" IMO.

Err... I think here I'll have to agree with Warp.  Why would you try to 
bypass the "code sanity checks" and all the paranoid safety devices to 
access something you shouldn't be accessing in the first place?

This thread has long derailed into something quasi-metaphysical... :P

My final word here is:  to have modularity you don't need all the traps, 
contraption devices and alarmist chainballs with all the barroque syntax 
associated.  All you need is to agree to use only what a module provides 
you.  It's your choice to be dumb enough or a smartass h4x0r and rip the 
contract just to show you can.

Post a reply to this message

nemesis wrote:
> Darren New escreveu:
>> Warp wrote:
>>> nemesis <nam### [at] gmailcom> wrote:
>>>>>   Ok, "written agreement" then, if you want to nitpick. Not much 
>>>>> difference.
>>>>> Still not enforced nor sanity-checked by anyone or anything.
>>>
>>>> Here is where Larry Wall's quote really applies. ;)
>>>
>>>   Since when have code sanity checks become a bad thing?
>>
>> When they become something to work around, rather than a help to the 
>> programmer. If you need to go read the source code of the module 
>> you're accessing to figure out how to get to the private variables, 
>> it's no longer a "code sanity check" IMO.
> 
> Err... I think here I'll have to agree with Warp.  Why would you try to 
> bypass the "code sanity checks" and all the paranoid safety devices to 
> access something you shouldn't be accessing in the first place?



Because, every once in a while, the provider of the library wasn't omniscient.

It's pretty simple. It's a practical thing. Say you have (just for an 
example) a video codec. It does all kinds of nice things with timestamps and 
such, but one thing it doesn't provide is telling you the current frame 
number. However, that is stored in a private variable (which you can see 
from reading the .h file), and for some reason you need that information to 
implement your player in an environment the original author didn't intend 
his player to be used in.

You have three choices:
1) Violate encapsulation, and pay the price if you ever need to use a new 
version of the decoder that doesn't have the frame number in the same place.

2) Rewrite the entire video decoder from scratch.

3) Find the owner of the original code and get him to change it and agree to 
support it indefinitely.

It's a cost vs benefit thing.


You "shouldn't" be accessing the internal data structures NTFS stores on the 
disk. It makes it kind of hard to make an open source NTFS driver without 
doing so. If your systems *really* prevented that access, such drivers would 
be impossible to write. When MS changes the NTFS drivers, Linux maintainers 
have to go in, reverse engineer things again, and fix stuff up to stay 
compatible. That's a cost that wouldn't be borne if Microsoft's NTFS was 
open source and there was only one code base.

Sure, if you have the source code to the module, providing public access to 
the private variable is pretty easy. I'd not recommend bypassing the 
protection mechanisms in that case. I thought that would be obvious to 
people, tho, so I assumed everyone was on the same page with me there. 
(Which is not to say anyone disagrees or has disagreed with that here.)



> This thread has long derailed into something quasi-metaphysical... :P

I'm thinking it's something very practical. I'm not advocating regularly 
accessing the internals of other objects. I'm just saying that preventing it 
by convention or by hiding information from the humans isn't any worse IMO 
than implementing it in the compiler.

> My final word here is:  to have modularity you don't need all the traps, 
> contraption devices and alarmist chainballs with all the barroque syntax 
> associated.  All you need is to agree to use only what a module provides 
> you.  

And to be able to tell easily when you're violating it. If you have to read 
prose documentation to know whether some routine or variable is private or 
public, *then* you lack modularity.

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

Darren New escreveu:
> nemesis wrote:
>> Err... I think here I'll have to agree with Warp.  Why would you try 
>> to bypass the "code sanity checks" and all the paranoid safety devices 
>> to access something you shouldn't be accessing in the first place?
> 
> Because, every once in a while, the provider of the library wasn't 
> omniscient.

You can also try another library. ;)

> And to be able to tell easily when you're violating it. If you have to 
> read prose documentation to know whether some routine or variable is 
> private or public, *then* you lack modularity.

Speaking purely from the point of view of Scheme and functional 
programming, there's no such a fuss:  all the module provides are public 
functions.  You just read their names and parameters and use them.

You can see from this thread that while it began with CLOS, it ended in 
C++ because of its tons of private, protected, friend and other 
schizophrenic access mechanisms leading to complicated interfaces and 
behavior for modules.

Post a reply to this message

nemesis wrote:
>> Because, every once in a while, the provider of the library wasn't 
>> omniscient.
> 
> You can also try another library. ;)

Well, yeah.

> You can see from this thread that while it began with CLOS, it ended in 
> C++ because of its tons of private, protected, friend and other 
> schizophrenic access mechanisms leading to complicated interfaces and 
> behavior for modules.

Actually, I thought it ended in C++ because that's the only unsafe OOP 
language I know of. It's the only language I know where the compiler 
attempts to enforce modularity but in practice fails to do so, by declaring 
violation of modularity "undefined" or "compiler-specific" rather than 
catching all cases of broken modularity at compile time or runtime.

I was trying to figure out how well-documented modularity breaking is a 
"kludge" but poorly documented unsupported modularity breaking isn't.

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

Darren New <dne### [at] sanrrcom> wrote:
> >   Could you give a concrete example of a compiler, of any OO language,
> > which will only *warn* (rather than give an error message) if you try to
> > access a member variable specifically marked as private from the outside?

> Sure. C# or Java. You get this warning that says "this won't compile."

  Wait. The compiler gives a *warning* which says "this won't compile"?
If it's just a warning, and not an error, it means that it will compile
it anyways? Isn't that contradictory?

> Another example is, as I've been saying, C++. The compiler warns (and won't 
> compile) if you access the private variable by name

  I get no warning if I try to access a private member. I get an error.
There's a big categorical difference.

>, but not if you 
> intentionally or accidentally access the private variable by address.

  You can't access the private variable by address. Not according to the
standard. If you can, then that can be considered a non-standard compiler
extension.

  And trashing memory, triggering UB, is not the same thing as "accessing
a member variable". The effect may be the same as accessing in one compiler,
but might not be in another. You are not *really* accessing it. You are
just abusing compiler and system specific undefined behavior.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   The question here is: Are compiler-enforced private member variables a
> good thing in programming or not?
> 
>   Your argument why they are not: In C++ you can accidentally access them
> regardless of the compiler checks.

Actually, let me ask this. Since you seem to be saying that reflection means 
that an OO system is a "kludge" because it breaks modularity, can you tell 
me what language *you* think isn't a kludge in this respect? Since the 
discussion mentioned "private:" and you defended the practice, I may have 
wrongly assumed that indicated that you thought C++ wasn't a kludge OOPL in 
this respect.

I don't know of any language that actually enforces modularity to the extent 
where it's impossible to write code that depends on private variables of 
another class, especially one to which you have the source. Every 
language[1] where the trivial ways of doing this (e.g., reading the source 
and using private names from outside the class) are enforced also has the 
ability to bypass it without too much trouble (either by using reflection or 
pointer arithmetic).

I don't know of any languages that make it trivially easy to *accidentally* 
confuse private and public member variables, except *perhaps* PHP and Perl, 
both of which I'll happily admit are kludges. :-) They might not make it 
trivial, I don't remember, but if they do, I'm not surprised.


[1] except perhaps Ada - I'd have to go look closer to see if unchecked 
conversions can do that sort of thing on tagged records.

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

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   I still can't comprehend what's so bad in the compiler doing the check
> > that you don't access the private members.

> If it's actually enforced (as in an error rather than a warning), it makes 
> lots of things harder than they need to be, because the running code winds 
> up with less information than the compiler had. You're throwing away half 
> the work the compiler did once you generate the code, so you wind up with 
> lots of boilerplate to enter into code things the compiler already knows.

  That's the whole idea in modular thinking: You don't know what's inside
the module, and you *don't care*. You don't need to care.

  As soon as you start worrying what's inside the module, you are already
breaking module boundaries and abstraction.

> If it's half-enforced, as in the compiler complains and won't compile the 
> code, but there's ways to get around it anyway (on purpose or by mistake), 
> then it's IMO the worst of all possible worlds. You'll spend hours or days 
> trying to debug code that's already right because the client is convinced 
> the other code they've written is bugfree and it's easier to blame you than 
> to find the wild pointer in their own code. The whole idea of class 
> invariants goes out the window.

  No you'll explain to me how a naming convention of public variables helps
this problem.

> Incidentally, I see little wrong with breaking encapsulation if you maintain 
> the invariants. It makes it harder to upgrade in the future without changing 
> the client, but that's the price you pay for it. If you can automate the 
> access to where it doesn't hurt to change the client, it seems like a 
> win-win to me.

  IMO if anyone feels the need to break your interface and access private
members directly, then your class design sucks and should be redesigned.

  If your class design is good, nobody will need to access anything
directly.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> 1) They're enforced 100%. Nobody outside the class is capable of writing to 
> or reading from a private variable. This provides maximum isolation at the 
> expense of not having available at runtime lots of stuff the compiler knows 
> at compile time that you might want to know (e.g., reflection type stuff). 

  If you need to know the private members of the class from the outside,
then that class has been badly designed.

  With a well-designed class you don't *need* to know, nor care.

> 2) They're enforced 100%, but people outside the class can read but not 
> write them. This is a little more fragile to change

  It breaks modularity badly. The whole idea of data hiding is that the
private part should be completely opaque to the outside. The second it
isn't, outside code will start making assumptions, and you can't change
the implementation of the class anymore.

> but still capable of 
> being debugged in isolation, because other parts of the code can't break 
> your invariants. Eiffel does this, but it's the same syntax (x.y) to 
> reference the y member of x as it is to invoke the nullary member function y 
> on x, so you don't need to do more than recompile the client code. (I think 
> you can also say a variable is completely private, IIRC.)

  Some people argue that accessors to all private members, especially if
they are automatically generated, is almost as bad as having all the
members public. It exposes the internal implementation, and thus outside
code will start making assumptions about it, making it harder to change
the implementation later.

  Some accessors may be justifiable, but you should not go overboard.

> 3) They're enforced, but there are explicit mechanisms to bypass them, such 
> as reflection. This is my personal preference, because it's easy to find the 
> places in the code that might be breaking your invariants or might rely on 
> your internal implementation, while providing the power of metadata. This is 
> the C# and Java model.

  If you don't have access to the code which is making assumptions about
your class' internal structure, you can't change your class without breaking
that existing code.

  Sure, this situation might not be extremely common, but it can happen.
And it's something which might have been avoided with a good interface
design and a completely opaque private implementation.

> 4) They're enforced by the compiler but not by the runtime. This removes 
> *both* the ability to debug your module in isolation *and* the ability to do 
> metaprogramming that eliminates boilerplate by using the information the 
> compiler has already calculated.

  Why would you want runtime checks if access rights could be fully checked
at compile time?

> 5) They're not enforced by the compiler or the runtime, but there are 
> conventions and/or standards that make it obvious to everyone when you're 
> breaking the data encapsulation, and the runtime ensures that you can only 
> do this "on purpose". That is, the unenforced conventions (or enforced but 
> bypassable mechanisms) ensure that the only way of breaking encapsulation is 
> on purpose. This is almost as good as #3, except it may be harder to track 
> down who is violating your invariants.

  Again, if you must keep "reverse compatibility", for a lack of a better
term (in other words, you as a library developer must maintain compatibility
with existing code which uses your library, and you don't have access to
this existing code nor can change it), it can be a problem if the existing
code can make assumptions about your library and does so.

> >   I think that your problem is that you have some kind of holy war against
> > C++, and every single discussion about programming is always somehow turned
> > to bashing C++.

> Nope. Someone brought up C++ by talking about the compiler enforcing 
> "private:". I was just pointing out that the compiler only enforces it in 
> some ways, and not in the ways that I thought was also important for modularity.

  You immediately assumed that it must be talking about C++, of course,
and immediately jumped at the opportunity of bashing it.

> >   I'm honestly getting tired of your C++ tirades. Every single subject
> > related to programming must somehow include C++ bashing, regardless of
> > the subject. That's getting tiresome.

> I'm really not trying to bash C++ here. If pointing out that C++ allows you 
> to corrupt member variables with a bug is "bashing", then I guess I'm bashing.

  In a discussion about the modular programming paradigm and data hiding you
succeeded in creating an lengthy thread about how you can trash memory in C++.
It's not exactly like you avoided the subject.

> OK. I'm just trying to communicate here. That's why I'm asking the question. 
> It seemed to me that you preferred a language with unsafe behavior and 
> compiler-enforced checks to one with safe behavior and no compiler-enforced 
> checks.

  That "you preferred a language with unsafe behavior" is 100% your own
invention. I have nowhere said that.

  What I have said is that I prefer enforced modularity over non-enforced
one (which IMO is not modularity at all). That "unsafe" bit is all your
own twisting.

> I've never heard you call C++ a kludge OO language. I assumed you were 
> excluding C++ from that criticism when you said a language that allows 
> access to private members is a kludge OO.

  At least you admit you are making assumptions.

-- 
                                                          - Warp

Post a reply to this message