Darren New <dne### [at] sanrrcom> wrote:
> >   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.

> It also prevents code from *inside* the module from doing certain things in 
> an easy way.

  Everything in the class is public to the class itself. I don't understand
your point.

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

> The naming convention doesn't help that. The safety of the language helps 
> that. In other words, what helps it is not the naming convention, but the 
> fact that code that accesses private variables *must* use the naming 
> convention to do so.

  So your solution to the problem of being able to modify private members
by accident because of the language being unsafe is to make the language
safe... and to make everything public (with a naming convention of
variables).

  I don't see how the latter follows.

> I'm just less worried about intentionally violating modularity than 
> accidentally doing so.

  Problems with programming errors in unsafe languages has nothing to
do with the subject of modularity.

  Accessing something out of boundaries by accident is always a bug
regardless of what effects that has. This has nothing to do with whether
modularity is a good thing or not.

> (I've had server code written in unsafe languages where it would dump core 
> on a segfault, and the providers wanted to blame it on the fact that the Xen 
> kernel was on the machine. We weren't booting Xen, but they wouldn't even 
> look at their code until we uninstalled that kernel. Just as an example of 
> how people can avoid admitting their own bugs might be part of the problem.

  And this has what to do with the original subject?

  You always succeed in returning to your favorite subject: Bashing
"unsafe" languages. And in your world there's only one such language: C++.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> 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.

Not all uses of reflection come from outside the class, and not all uses of 
reflection violate modularity. For example, the ability to instantiate an 
instance of a class whose name you have in a string is technically 
"reflection". That doesn't break modularity.

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

Right. That's what I meant by "it's more fragile to change."

>   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 seems semantically identical to me. :-) Of course, if you can override 
the private accessors, you might be able to keep some sorts of compatibility.

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

Agreed. I'm not advocating that people access private members without 
knowing what they're doing and why. I'm not advocating they access private 
members when they can change the module to reveal what they need revealed.


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

It depends what assumptions are being made by the code you don't have.  It's 
also the case that it's not uncommon for things like reflection to be used 
internally to the class or the module to replace what would otherwise be 
fragile boilerplate code.

If the code that violates modularity adjusts automatically when you change 
the class being violated, it's in practice capable of handling far more 
kinds of changes than one might expect.

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

Agreed. The problem comes when you're stuck with a bad interface design and 
an opaque implementation. :-)  Surely, you don't imagine that reading the 
source code of a class implementation and then using internal functions to 
get the values of private variables is a normal way of programming LISP objects?

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

I wouldn't. I don't know any languages that fully check access rights at 
compile time that don't provide well-defined standard mechanisms for 
bypassing them at need.

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

Agreed. But I don't know of any language that doesn't let you get into that 
situation. It's just a question of how easy or hard it is, and how obvious 
it is that it's happening.

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

Well, the first thing I objected to is the idea that a language is kludgey 
if you can access private variables whose names only appear in the source 
code of the class implementation.

My first mention of C++ (in the same paragraph where I meantioned another 
half-dozen OO languages) was that it's trivial to bypass the modularity of 
it, meaning that you can read and write private members of a class by using 
well-defined if non-portable operations. I then asked you if you didn't 
think that meant modularity was lacking in C++.

Actually, you mentioned "private:" first, and I admit I assumed you were 
talking about C++, since the only other languages I know that use that 
syntax are ones you'd already said are kludgey.

I think we're just off on the wrong foot here, perhaps. You said "data 
hiding is an integral part of OO" and criticized CLOS for not having it. Yet 
the only way to unhide the private data in CLOS is to read the source code 
for the implementation of the class. Hence, it seems you were saying that 
any mechanism that allows the access of private members, even with complete 
access to the source, is a bad thing (assuming you think kludges are bad). 
Yet I can get access to the private members of *every* language that has the 
"private:" syntax. C++ is the only language I know that use that syntax that 
doesn't have a standard way of accessing private variables. All C++ has is 
non-portable (but standard) ways of accessing private variables. So I talked 
about C++.

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

No, I didn't avoid it. There was an implication that C++ had better 
modularity and data hiding than languages with reflection implemented 
standardly. I'm pointing out that it doesn't. You can dump an instance into 
an array of characters and rebuild whatever you need, if you accept you'll 
have a non-portable knowledge of how the class is laid out.

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

Are you missing the "it seemed to me" bit there? Do you not understand what 
that phrase means? It means "Hey, we seem to have a miscommunication going 
on. This is what I received. Is it what you meant?"  That doesn't mean I'm 
"twisting" your words. It means I'm asking you to clarify.

>   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 prefer enforced modularity over non-enforced modularity myself. I know of 
virtually no language that supports enforced modularity. They all have 
specific trap doors just to get around the modularity restrictions. (Except 
perhaps Ada and Eiffel, neither of which is a really a language I use enough 
to be sure of.)

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

Yeah. Sure. That's a basic part of communication. That's why my comments are 
full of things like "it seems to me..." and "are you saying that..." 
They're indicators that I'm making assumptions that need to be validated. It 
doesn't mean I'm saying you said that. It means it sounds to me like you're 
implying that, and I'm asking if I'm interpreting you correctly.

-- 
   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:
> Darren New <dne### [at] sanrrcom> wrote:
>> 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
> 
>   In fact I said that trying to emulate OOP in a language which has no
> direct support for OOP is a kludge. The only thing I said about reflection
> is that IMO it breaks modularity and thus you lose many of the benefits of
> modular design.

Fair enough. I misremembered precisely what you said, and went with the 
logical implication that seemed to follow.

I'll still disagree that emulating OO with closures in LISP is a kludge, 
because other features of LISP provide direct support for changing the 
language to support other features directly. Once you hit that meta-level of 
support, it's a whole new ball of wax.

-- 
   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:
> Darren New <dne### [at] sanrrcom> wrote:
>> Actually, I thought it ended in C++ because that's the only unsafe OOP 
>> language I know of.
> 
>   I can't understand if that means "I haven't studied unsafe OOP languages
> other than C++" or "to my knowledge there are no other unsafe OOP languages".

There are few other unsafe OOP languages I know enough about to discuss. Ada 
and C++ are the only unsafe OOP languages I know, and I don't know Ada well 
enough to know what bad code is erroneous and what bad code is simply UB in 
Ada.

>> 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.
> 
>   Then you don't know much, do you.

Possibly. What OO languages do you know of where the compiler attempts catch 
all violations of modularity at compile time but in practice fails to do so?

>> I was trying to figure out how well-documented modularity breaking is a 
>> "kludge" but poorly documented unsupported modularity breaking isn't.
> 
>   The connection between my usage of the word "kludge" and your usage
> of the words "unsafe" and "reflection" is purely your invention.

OK. I was confused by the fact that your post had
1) A paragraph about how CLOS allows access to the private variables,
2) a comment about languages lacking data hiding aren't really OO,
3) a lack of specific support for hiding means the OO is kludgey.

I leapt to the conclusion that in 2 and 3 you were actually talking about 
the same thing as you were talking about in 1. That was a bad assumption, 
and started me arguing that CLOS has a reasonable degree of modularity built 
in.

If you weren't talking about CLOS in 2 and 3, I'm not really sure why you 
quoted (1) there.

If you *were* talking about CLOS, I'm arguing that there isn't to my 
knowledge any OO language that does a better job. And none that I know of 
that use "private:".

-- 
   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:
> Darren New <dne### [at] sanrrcom> wrote:
>>>> 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.
> 
>   You didn't answer my question.

You said the designs of C# and Java are badly broken because they let you 
get to the private variables of an instance using reflection. You then said 
C++ doesn't let you get to a private variable of an instance. I was 
disputing that claim. That's what compiler-enforced data hiding has to do 
with C++.

>   "Is enforced data hiding a good thing or a bad thing?"
>   "In C++ you can bypass the encapsulation, so it's a bad thing."

You skipped a bunch of context in between that I thought still applied. 
Maybe you're reading messages in a different order than I am. That's one of 
the problems when a conversation really gets going online. :-)

If you're not going to apply that context, see my other messages where I 
explain the types of access and seem to be mostly in agreement with you.

>>>   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. :-)

>   It's getting really tiresome and old.

I didn't start out bashing C++ this time. We got pretty far until you 
*seemed to* claim C++ was better at modularity than C# or Java or CLOS. I 
merely listed C++ amongst a half-dozen languages I was criticizing for 
different individual design choices.

-- 
   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:
> Darren New <dne### [at] sanrrcom> wrote:
>>>   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.
> 
>> It also prevents code from *inside* the module from doing certain things in 
>> an easy way.
> 
>   Everything in the class is public to the class itself. I don't understand
> your point.

I can use reflection to iterate over my own member variables without 
breaking modularity. I can use reflection to look at the documentation of 
other classes without breaking modularity. I can use reflection to 
instantiate an instance of a class whose name is in a string without 
breaking modularity.

My point is that not all uses of reflection are kludgey, and including it in 
a language doesn't mean the design of the language is badly broken.

For further examples, peek at the Google API for database interaction on 
Google App Engine. For example, looking at
http://code.google.com/appengine/docs/python/gettingstarted/usingdatastore.html
you can see how a "Greeting" class is declared, a "greetings" 
list-of-greeting is created by db.GqlQuery(), and later the elements of that 
list are accessed via greeting.author syntax. How does db.GqlQuery() create 
a greeting instance and fill in the author based on the names of the rows of 
the database? Reflection.

>   So your solution to the problem of being able to modify private members
> by accident because of the language being unsafe is to make the language
> safe... and to make everything public (with a naming convention of
> variables).
> 
>   I don't see how the latter follows.

No. Making it safe and not making everything public and not needing naming 
conventions is best. That's what CLOS does, modulo reading the source and 
invoking interpreter-internal routines with the names of private variables. 
That's what C# does, modulo the reflection libraries. That's what C++ does, 
modulo using pointers and UB.

It would be better, of course, if languages like Python didn't expose 
private variables unless you were intentionally doing meta-programming. But 
Python has all kinds of hacks to let you control access to variables. For 
example, there's even a case where if you type
    x = y.z
and y.z's *value* has a method called __getvalue__ (or some such name) then 
the return value of invoking that method is what actually goes into x. So, 
yeah, there's a lot of non-OO stuff going on there.

>> I'm just less worried about intentionally violating modularity than 
>> accidentally doing so.
> 
>   Problems with programming errors in unsafe languages has nothing to
> do with the subject of modularity.

I disagree, as I've explained. There's two aspects to modularity, only one 
of which is addressed by unsafe languages.

>   Accessing something out of boundaries by accident is always a bug
> regardless of what effects that has. This has nothing to do with whether
> modularity is a good thing or not.

Modularity is a good thing. The inability to violate modularity by mistake 
is a good thing, don't you think?


>> (I've had server code written in unsafe languages where it would dump core 
>> on a segfault, and the providers wanted to blame it on the fact that the Xen 
>> kernel was on the machine. We weren't booting Xen, but they wouldn't even 
>> look at their code until we uninstalled that kernel. Just as an example of 
>> how people can avoid admitting their own bugs might be part of the problem.
> 
>   And this has what to do with the original subject?

That when modularity can be accidentally violated, it can be difficult to 
debug, in part because those with the accidental bug can be reluctant to 
admit they have a bug when it's actually the violated module that's crashing.

Again, the point is there's two parts of modularity: future upgrade 
proofing, and class invariant maintenance. I think they're both important. 
You seem to be completely ignoring any discussion of the second part.

>   You always succeed in returning to your favorite subject: Bashing
> "unsafe" languages. And in your world there's only one such language: C++.

Not at all. Lots of unsafe languages are out there - C and assembler both 
spring to mind. I don't know of many unsafe OO languages, is all. C++ is the 
only OO language I know where the default operation of the language is to be 
unsafe, rather than it being used as a well-labeled escape hatch where 
necessary for performance. Doing unsafe things when you declare them after a
#pragma UNSAFE
for example doesn't seem to be a "kludge" in the language design to me.

-- 
   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 wrote:
> My point is that not all uses of reflection are kludgey, and including 
> it in a language doesn't mean the design of the language is badly broken.

Oh, and a lot of these language use reflection to implement debuggers, 
performance monitors, and unit test frameworks. :-) None of which I'd call 
kludges or violations of modularity.

Funny enough, every Python class and method has documentation that's 
included in the class (in a member called "__doc__"). There are python test 
frameworks that go thru all your classes and members, finding the document 
strings, looking for something that looks like the result of running tests 
interactively in the doc string, then runs the tests and compares the results.

http://docs.python.org/library/doctest.html

The stuff in the blue strings, with >>> marking the calls (which is the 
default python interactive interpreter prompt) gets run by this library, 
which then tells you what failed after comparing the results to the 
documentation.

In this case, the documentation for the class includes its own simple tests, 
which I thought was pretty cool.

Sure, you can do all this sort of stuff with preprocessors generating code, 
but that's just because compilers have all the information that reflection 
is supposed to make available.

As an aside, there's actually a lack in the terminology. I use the term 
"reflection" to mean looking at the source code while it runs, and 
"introspection" to mean looking at the process while it runs. So the 
question of "what member variables does class XYZ have" is reflection, and 
"what's the name of the method two stack frames up from here" is 
introspection. Unfortunately, I don't think I've convinced anyone else to 
make that distinction. :-)

-- 
   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:
> OK. I was confused by the fact that your post had
> 1) A paragraph about how CLOS allows access to the private variables,
> 2) a comment about languages lacking data hiding aren't really OO,
> 3) a lack of specific support for hiding means the OO is kludgey.

Me too.

Post a reply to this message

Warp wrote:
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> Instead of using private:, you could just add an underscore to internal
>> variables.
> 
>   But why would I want to do that? There's no benefit. There are only
> potential disadvantages.

Because Python has no real "private", and in practice the underscore seems
to work well enough.

Post a reply to this message

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

It's not bad to have the compiler do that, it's good.

But some languages don't have that feature, and that doesn't make them bad
either.

Post a reply to this message

Darren New wrote:
> No. Making it safe and not making everything public and not needing naming
> conventions is best. That's what CLOS does, modulo reading the source and
> invoking interpreter-internal routines with the names of private
> variables. That's what C# does, modulo the reflection libraries. That's
> what C++ does, modulo using pointers and UB.

That's not a good comparison.

C# has a way to access private data through reflection. Python has a way to
access private data by just doing it (but you'll know you're doing it
because there is an underscore).

C++ has no way to access private data. If you say pointers and UB are
a "valid" way to access private data, then I'd say attaching a debugger to
the .NET virtual machine and poking at its memory is a valid way too.

Post a reply to this message

Warp wrote:
>   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.

You CAN change the implementation of the class. It's not your problem if you
break code that made assumptions.

Post a reply to this message

Nicolas Alvarez wrote:
> Darren New wrote:
>> No. Making it safe and not making everything public and not needing naming
>> conventions is best. That's what CLOS does, modulo reading the source and
>> invoking interpreter-internal routines with the names of private
>> variables. That's what C# does, modulo the reflection libraries. That's
>> what C++ does, modulo using pointers and UB.
> 
> That's not a good comparison.
> 
> C# has a way to access private data through reflection. Python has a way to
> access private data by just doing it (but you'll know you're doing it
> because there is an underscore).
> 
> C++ has no way to access private data.

memcpy. Check the standard under 3.9. It's therein defined how you can 
access and modify the private data of a class in C++ (and in a 
standards-conforming way if it's POD). Consider the case of "class alpha 
{int abc;}" for a counter-example - I know exactly how that's laid out due 
to the standard. It's perfectly standard-conforming to pass a pointer to an 
instance of class alpha to both memcpy and memset.

In any case, C++ *DOES* in *practice* have a way to access private data, 
even without that, because it's not safe. It's not clean and portable, but 
if there wasn't any way to access private data, we'd have far fewer sigsegv's.

I guess there's two ways you could argue it:
1) C++ in theory disallows access to private variables but in practice every 
known implementation allows it, because it's actually virtually impossible 
to follow the rules of the standard while disallowing said access.
2) LISP in theory allows access to private variables even though it's 
impossible to do by accident and you have to read the source for the 
implementation of the class (which you might not have) to learn the 
variables. (Actually, has anyone checked whether the Common Lisp standard 
actually guarantees you'll be able to get to private variables, or is that 
just the current implementations?)

Sure, in theory, great.

In practice, nobody uses a C++ compiler that prevents access (intentional or 
otherwise) to private variables, and in practice, nobody uses private 
variables of a class that haven't been exported except as a last resort.

Since we're talking about practical benefits (like being able to modify 
code), I was taking the latter approach.

In any case, even if we took reflection out of C# and Java, it's still 
possible to declare unsafe pointers in C# and "native code" in Java that can 
change private variables in a more-or-less well-defined way. Except you're 
now doing it exactly the same way as C++ would, except for the fact that 
again you've flagged your source code as "hey, I'm doing this on purpose". 
I'm not sure how that should "count".

-- 
   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:
>   You always succeed in returning to your favorite subject: Bashing
> "unsafe" languages. And in your world there's only one such language: C++.

You know something?  It's getting "really tiresome and old" that every time 
I list problems with 5 or 6 different languages, you think I'm bashing on 
C++. It's getting "really tiresome and old" that every time I point out 
something that Windows does well, I'm told I'm bashing on Linux. It's 
getting "really tiresome and old" that every time I point out problems with 
unsafe languages in general, you think I'm bashing solely on C++. It's 
getting "really tiresome and old" that every time I talk about automatic 
resource management you think I'm bashing C++. It's getting "really tiresome 
and old" that most times you tell me I'm ignorant and I ask you for more 
information, you ignore that request, preferring just to insult me rather 
than actually provide information that might improve the conversation.

I think I've expressed my point of view, and I think you all understand what 
I'm saying but for some reason feel the need defend C++ instead of 
discussing the pros and cons rationally and conversationally. I can't add 
any further information by pursuing this conversation, altho I've left 
several questions open in various posts that could be productively answered.

-- 
   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:
> Consider the case of "class alpha 
> {int abc;}" for a counter-example - I know exactly how that's laid out due 
> to the standard.

  I don't think the standard specifies what kind of padding the compiler
will use between member elements.

  For example, if you have a "struct { char c; int i; };", how many bytes,
if at all, are there between 'c' and 'i'?
  Suppose you have "struct { int i; long l; };" in a 64-bit system. Will
the compiler put padding bytes between 'i' and 'l' or not?

  Suppose you have:

class A {};
class B: public A { int i; };

  sizeof(A) will be, per the C++ standard, at least 1. But what will be
sizeof(B), and consequently the offset of 'i' inside it? The standard
doesn't specify, and the compiler is free to optimize the empty base
class away or not, as it sees fit.

  Oh, and it becomes even more complicated:

class A { int i1; public: virtual ~A(); };
class B1: virtual public A { int i2; };
class B2: virtual public A { int i3; };
class C: public B1, public B2 { int i4; };

  Want to start guessing the offsets of the ints inside C? Good luck.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   You always succeed in returning to your favorite subject: Bashing
> > "unsafe" languages. And in your world there's only one such language: C++.

> You know something?  It's getting "really tiresome and old" that every time 
> I list problems with 5 or 6 different languages, you think I'm bashing on 
> C++.

  5 or 6 different languages? Really?

  You started by making a reference to "unsafe languages" within the subject
of modular programming as a reply to one of my posts (clearly as a reference
to C++), and later you said that C++ is the *only* unsafe OO language you
know of. After that you have been done nothing else than arguing why
modularity in C++ is broken and why Lisp, Java and C# are so great.

  It was certainly not me who brought up C++ into the conversation.

  Yeah, sure. You really have been pointing out problems in "5 or 6 different
languages", and I'm just being paranoid that you are concentrating a little
too much on C++.

> It's getting "really tiresome and old" that every time I point out 
> something that Windows does well, I'm told I'm bashing on Linux.

  Every time? When was the last time?

> It's 
> getting "really tiresome and old" that every time I point out problems with 
> unsafe languages in general, you think I'm bashing solely on C++.

  You explicitly wrote that C++ is the only unsafe OO language you know of.
You have been writing specifically about C++, not about "unsafe languages
in general".

> It's 
> getting "really tiresome and old" that every time I talk about automatic 
> resource management you think I'm bashing C++. It's getting "really tiresome 
> and old" that most times you tell me I'm ignorant and I ask you for more 
> information, you ignore that request, preferring just to insult me rather 
> than actually provide information that might improve the conversation.

  And it's getting really tiresome and old that you act all innocent after
a tirade of C++ bashing, saying that "I just wanted a serious discussion
and honestly wanted to know more", when it's rather clear that you didn't
really.

  It's also getting tiresome that every time I criticize some other language
you immediately assume I'm defending C++. For example, if I call some other
language "kludgey", you immediately assumed that I'm claiming that C++ is
not, even though I never said anything of the sorts. And of course you
immediately jumped to the opportunity of starting bashing.

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Warp wrote:
> >   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.

> You CAN change the implementation of the class. It's not your problem if you
> break code that made assumptions.

  I don't think that's a good programming principle.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> There are few other unsafe OOP languages I know enough about to discuss. Ada 
> and C++ are the only unsafe OOP languages I know

  Ok, here's a couple more:

- Objective-C. Regardless of the name, has nothing to do with C++.
- C#. Regardless of the name, has nothing to do with C++.

> >   The connection between my usage of the word "kludge" and your usage
> > of the words "unsafe" and "reflection" is purely your invention.

> OK. I was confused by the fact that your post had
> 1) A paragraph about how CLOS allows access to the private variables,
> 2) a comment about languages lacking data hiding aren't really OO,
> 3) a lack of specific support for hiding means the OO is kludgey.

  I still see no connection to "unsafe" languages and "reflection". Those
were your inventions.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >>>> 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.
> > 
> >   You didn't answer my question.

> You said the designs of C# and Java are badly broken because they let you 
> get to the private variables of an instance using reflection. You then said 
> C++ doesn't let you get to a private variable of an instance. I was 
> disputing that claim. That's what compiler-enforced data hiding has to do 
> with C++.

> >   "Is enforced data hiding a good thing or a bad thing?"
> >   "In C++ you can bypass the encapsulation, so it's a bad thing."

> You skipped a bunch of context in between that I thought still applied. 
> Maybe you're reading messages in a different order than I am. That's one of 
> the problems when a conversation really gets going online. :-)

> If you're not going to apply that context, see my other messages where I 
> explain the types of access and seem to be mostly in agreement with you.

> >>>   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. :-)

> >   It's getting really tiresome and old.

> I didn't start out bashing C++ this time. We got pretty far until you 
> *seemed to* claim C++ was better at modularity than C# or Java or CLOS. I 
> merely listed C++ amongst a half-dozen languages I was criticizing for 
> different individual design choices.

  You are seriously claiming that when you wrote "like, in unsafe languages,
where a stray pointer can change private variables without going thru the
class methods? :-)" as a reply to my post you were not directly and
exclusively referencing C++, especially with that smiley?

  What other half-dozen "unsafe languages, where a stray pointer can change
private variables" were you talking about there?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Consider the case of "class alpha 
>> {int abc;}" for a counter-example - I know exactly how that's laid out due 
>> to the standard.
> 
>   I don't think the standard specifies what kind of padding the compiler
> will use between member elements.

It specifies that the first element has no padding before it.

>   For example, if you have a "struct { char c; int i; };", how many bytes,
> if at all, are there between 'c' and 'i'?

That's a different example, yes.  It's going to be compiler/architecture 
dependent.

>   Oh, and it becomes even more complicated:
> 
> class A { int i1; public: virtual ~A(); };
> class B1: virtual public A { int i2; };
> class B2: virtual public A { int i3; };
> class C: public B1, public B2 { int i4; };
> 
>   Want to start guessing the offsets of the ints inside C? Good luck.

I don't think the standard says what the offsets are for classes with 
virtual destructors.

-- 
   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:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>   You always succeed in returning to your favorite subject: Bashing
>>> "unsafe" languages. And in your world there's only one such language: C++.
> 
>> You know something?  It's getting "really tiresome and old" that every time 
>> I list problems with 5 or 6 different languages, you think I'm bashing on 
>> C++.
> 
>   5 or 6 different languages? Really?

Yeah. LISP, Java, C#, C++, Python, and Ada. That's the first post I said 
anything that could conceivably imply C++ wasn't perfect. I pointed out how 
you could violate encapsulation in each of them.

>   You started by making a reference to "unsafe languages" within the subject
> of modular programming as a reply to one of my posts

Yes.

>(clearly as a reference to C++), 

Except I specificly used the phrase "unsafe languages" because I knew if I 
said "C++" you'd go off the handle.  I was particularly pointing out that 
unsafe languages let you violate modularity. Whether it's OO modularity or 
non-OO modularity is irrelevant to whether unsafe languages let you violate 
modularity.

 > and later you said that C++ is the *only* unsafe OO language you
> know of.

But it's not the only unsafe modular language I know. But you were talking 
about OO in addition to modularity, so that's why it came up.

> After that you have been done nothing else than arguing why
> modularity in C++ is broken and why Lisp, Java and C# are so great.

I haven't said the others were great. I simply said I preferred the 
imperfections in C# to the imperfections in C++.

>   Yeah, sure. You really have been pointing out problems in "5 or 6 different
> languages", and I'm just being paranoid that you are concentrating a little
> too much on C++.

Honestly, it really seems like that to me. I'm sorry you have so much of 
your ego bound up in a programming language.

>> It's 
>> getting "really tiresome and old" that every time I point out problems with 
>> unsafe languages in general, you think I'm bashing solely on C++.
> 
>   You explicitly wrote that C++ is the only unsafe OO language you know of.

Yes, after you asked me about it.  I also asked you to name another unsafe 
OO language, but you didn't. There are other OO languages that you can 
bypass the safety on, but most people using them don't without knowing what 
they're doing, specifically for performance.

> You have been writing specifically about C++, not about "unsafe languages
> in general".

No. I was writing about unsafe modular languages. It turned into C++ after a 
while, when people started specifically saying you can't bypass the 
modularity in C++ like you can in the other languages.

>   And it's getting really tiresome and old that you act all innocent after
> a tirade of C++ bashing, saying that "I just wanted a serious discussion
> and honestly wanted to know more", when it's rather clear that you didn't
> really.

Well, if you start out with that assumption, I guess anything I say can be 
twisted to read that way.

-- 
   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:
> Darren New <dne### [at] sanrrcom> wrote:
>> There are few other unsafe OOP languages I know enough about to discuss. Ada 
>> and C++ are the only unsafe OOP languages I know
> 
>   Ok, here's a couple more:
> 
> - Objective-C. Regardless of the name, has nothing to do with C++.

Hmm. Yes, ok, I'd forgotten about that one, since I looked at it way back in 
the NeXT days but never used it. Very good, thanks. That's another example 
of an unsafe OO language where the lack of safety can lead to lack of 
modularity with all the same problems as C++.

> - C#. Regardless of the name, has nothing to do with C++.

C# is only unsafe if you specifically tell it "hey, I'm doing something 
unsafe."  That doesn't really count, any more than a safe language that can 
call out to C libraries is "unsafe".

>   I still see no connection to "unsafe" languages and "reflection". Those
> were your inventions.

Yes. It's part of an ongoing conversation, you see. "Access to private 
members violates encapsulation."   "Yes, and here's other ways to violate 
encapsulation."  See?

-- 
   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:
>   You are seriously claiming that when you wrote "like, in unsafe languages,
> where a stray pointer can change private variables without going thru the
> class methods? :-)" as a reply to my post you were not directly and
> exclusively referencing C++, especially with that smiley?

Yes. I am seriously claiming that. The smiley is there to say "Gee, I bet 
Warp will assume I'm for some reason attacking him. Maybe I'll try to be 
friendly and head that off."

If I was intentionally tweaking you, I'd use a winky face. :-)

>   What other half-dozen "unsafe languages, where a stray pointer can change
> private variables" were you talking about there?

C, for one. Any of the usually-safe languages that specifically bypass the 
safety features, like Ada using unchecked features or Eiffel with the 
precondition checking compiled out.

-- 
   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:
> > - C#. Regardless of the name, has nothing to do with C++.

> C# is only unsafe if you specifically tell it "hey, I'm doing something 
> unsafe."  That doesn't really count

  Of course it doesn't.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   What other half-dozen "unsafe languages, where a stray pointer can change
> > private variables" were you talking about there?

> C, for one.

  Except that C doesn't have private variables.

-- 
                                                          - Warp

Post a reply to this message

Warp escreveu:
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> Warp wrote:
>>>   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.
> 
>> You CAN change the implementation of the class. It's not your problem if you
>> break code that made assumptions.
> 
>   I don't think that's a good programming principle.

Me neither.  But that's a bad programming principle by the dumbass 
accessing stuff it shouldn't.  It's not your fault as the module 
provider and is beyond your control.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> - C#. Regardless of the name, has nothing to do with C++.
> 
>> C# is only unsafe if you specifically tell it "hey, I'm doing something 
>> unsafe."  That doesn't really count
> 
>   Of course it doesn't.

Or, at least, it falls into the same category as using reflection. :-)

-- 
   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:
> Darren New <dne### [at] sanrrcom> wrote:
>>>   What other half-dozen "unsafe languages, where a stray pointer can change
>>> private variables" were you talking about there?
> 
>> C, for one.
> 
>   Except that C doesn't have private variables.

Sure it does. Everything in a FILE structure is a private variable. 
Everything on the stack is private variables. You're reading things too 
narrowly.

-- 
   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:
>   You are seriously claiming that when you wrote "like, in unsafe languages,
> where a stray pointer can change private variables without going thru the
> class methods? :-)" as a reply to my post you were not directly and
> exclusively referencing C++, especially with that smiley?

BTW, I think it's at least as realistic a claim as

 >  The connection between my usage of the word "kludge" and your usage
 > of the words "unsafe" and "reflection" is purely your invention.

Seriously, I'm willing to admit we seem to miscommunicate a lot. But telling 
me I'm always misinterpreting you, then telling me I'm lying when I tell you 
you're misinterpreting me is a bit unpleasant.

-- 
   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:
> He's saying that putting "private:" before the variables in a class 
> declaration is equivalent to naming private variables with an underscore. In 
> the first case, the compiler warns you if you use a private variable by 
> mistake. In the second case, it's obvious from inspection. If you have
>     x._y
> in your code, you're doing something wrong. :-)

  Btw (not flaming here), what would be the naming convention for nested
classes? Take, for example, this kind of situation, in C++ code:

class OuterClass
{
 public:
    // Public interface here.

 private:
    // Outside code should not access anything from this point forwards.
    // This includes the 'InnerClass' class below.

    class InnerClass
    {
     public:
        // Public interface for OuterClass to use.

     private:
        // Private members of InnerClass. OuterClass should not access.
    };
};

  While it becomes complex, it's possible to have even a *third* nested
class, inside 'InnerClass', with the equivalent access rules.

  (Defining 'InnerClass' outside of 'OuterClass' is not a viable solution
if I really want 'InnerClass' to be strictly inside the scope of
'OuterClass' and nowhere else, because my class design calls for this.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> He's saying that putting "private:" before the variables in a class 
>> declaration is equivalent to naming private variables with an underscore. In 
>> the first case, the compiler warns you if you use a private variable by 
>> mistake. In the second case, it's obvious from inspection. If you have
>>     x._y
>> in your code, you're doing something wrong. :-)
> 
>   Btw (not flaming here), what would be the naming convention for nested
> classes? Take, for example, this kind of situation, in C++ code:

Python is kind of funky in this respect. Nested classes (or functions, or 
etc) don't have access to the private variables of the classes they're 
nested in.  They can only get locals, globals, or built-ins. A lambda 
expression can, but that's not a separate class as such, but just an unnamed 
function.

Depending on which naming convention you're talking about, class beta nested 
inside class alpha would be alpha.beta (if it's a public class), or 
alpha._beta if it's a private class.

In python, classes are values just like strings and lists and such. You can 
even instantiate classes without using the normal syntax, just by invoking 
the appropriate constructor for type "class". The syntax
    class abc:
       ...
just invokes that constructor and assigns the result to the variable abc 
(which creates the variable in that namespace if it doesn't already exist).

So if you nest alpha within beta like this
class beta:
    static_one = 1
    static_two = 2
    def beta_add(self,x,y):
       return x + y
    class alpha:
      root = 27
      def alpha_add(self,x,y):
         return x + y + root
then you get beta.static_one and beta.static_two and beta.beta_add and 
beta.alpha. You also get beta.alpha.root and beta.alpha.alpha_add.
Alpha can't access beta.static_one without using a dot. Beta can access 
alpha (as in "new alpha" sort of thing) without a dot, because alpha is a 
static variable of class beta.

But the namespaces that routines in alpha can access don't include the 
namespace that beta uses, and vice versa.

Hence, to get to alpha from outside of beta there, you need to say beta.alpha.

If you want alpha to be private to beta, so beta is (say) your linked-list 
class and alpha is a single link, you use "class _alpha:" instead, which 
indicates that beta._alpha is meant to be private to beta.

If you want alpha to be public, you name it "class alpha:" and others refer 
to it as beta.alpha.

Does that answer it? I probably gave way more details than you were actually 
asking about. :-)

The same naming convention holds for what you'd call "member variables" in 
C++, member functions, static variables/functions, nested classes, etc. 
Everything gets assigned to a variable. If you want gamma to implement the 
same foobar function as delta does, you can just write
    gamma.foobar = delta.foobar
and they're both the same function afterwards.

-- 
   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:
> Does that answer it? I probably gave way more details than you were actually 
> asking about. :-)

  I actually didn't understand your answer. There might have been some
miscommunication.

  Let me restate:

  There's a class named 'OuterClass', which has a public interface for
everything else to use, and a private part which is used only by 'OuterClass'
itself, and should be accessed by anything else.

  This private part declares another class named 'InnerClass'. This class
in question is part of the private implementation of 'OuterClass', and thus
should not be used in any way from the outside. However, 'OuterClass' itself
can, naturally, use it as usual.

  However, 'InnerClass' itself also has a public and a private part: The
public part defines the interface for 'OuterClass' to use. The private
part is for the internal implementation of 'InnerClass' itself, and shouldn't
be accessed by 'OuterClass'.

  The question is: If we are using a naming convention to denote public
and private data, how do you name 'InnerClass' and its private members?

  Since 'InnerClass' is part of the private implementation of 'OuterClass'
and thus should be used from the outside, I assume that the convention is
to call it '_InnerClass' (or whatever). The underscore denotes "don't
use this class from outside 'OuterClass', because it's private".

  How how do you name the members of this '_InnerClass'? All of its
members, even those in the public interface, are part of the private
implementation of 'OuterClass' and thus shouldn't be used from outside,
so do you put underscores in all the members, even public ones?

  What about the private members of '_InnerClass'? How do you differentiate
them from the private members of 'OuterClass'?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   The question is: If we are using a naming convention to denote public
> and private data, how do you name 'InnerClass' and its private members?

Got it.

OuterClass
OuterClass._private_static_of_OC
OuterClass.public_static_of_OC
OuterClass._InnerClass
OuterClass._InnerClass.used_by_outerclass
OuterClass._InnerClass._Used_only_by_innerclass

Does that clarify?

OuterClass could invoke
    x = _InnerClass.used_by_outerclass

The trick is you shouldn't write "._" as part of a reference. :-)

>   How how do you name the members of this '_InnerClass'? All of its
> members, even those in the public interface, are part of the private
> implementation of 'OuterClass' and thus shouldn't be used from outside,
> so do you put underscores in all the members, even public ones?

Oh, no. InnerClass isn't really "part" of outer class. It's just a class 
that happens to be created while creating InnerClass and assigned to a 
static variable of InnerClass.

Python doesn't have declarations, even of classes and functions and methods. 
It has statements that have lumps of code in them and creates an instance of 
a function object or an instance of a class object, and then assigns it to 
the name you gave the statement.  So there's no real relationship between 
InnerClass and OuterClass, any more than you have a relationship between a 
sphere object and the texture on the sphere. There's a relationship there, 
but it's not a relationship having to do with types, but rather with 
pointers to instance objects.  Kind of like javascript in that respect.

>   What about the private members of '_InnerClass'? How do you differentiate
> them from the private members of 'OuterClass'?

The private members of _InnerClass have _ on the front. _InnerClass can't 
access OuterClass's private or public variables without going through the 
class or instance dot-notation.

InnerClass and OuterClass are two 100% separate and independent classes. You 
could get *exactly* the same result by declaring it this way:

class InnerClass:
    .....

class OuterClass:
    ...
    _InnerClass = InnerClass
    ...
(Except of course now InnerClass has a global name also)

A nested class definition says "Create a new instance of type 'class' and 
assign it to this name in my namespace."  But that doesn't give the nested 
class any access that any other class could have, and vice versa. It's just 
a different name for a class. InnerClass doesn't have anything that points 
to the parent class, so there's no way to get to anything in the parent 
class directly from InnerClass. If the parent class has a global name like 
"OuterClass", then you can refer to that, of course, but there's nothing 
that tells InnerClass it's "part of" outerclass.

-- 
   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:
> >   The question is: If we are using a naming convention to denote public
> > and private data, how do you name 'InnerClass' and its private members?

> Got it.

> OuterClass
> OuterClass._private_static_of_OC
> OuterClass.public_static_of_OC
> OuterClass._InnerClass
> OuterClass._InnerClass.used_by_outerclass
> OuterClass._InnerClass._Used_only_by_innerclass

> Does that clarify?

> OuterClass could invoke
>     x = _InnerClass.used_by_outerclass

> The trick is you shouldn't write "._" as part of a reference. :-)

  But an outside code could do something along the lines of:

OuterClass::_InnerClass obj; // Assuming the compiler doesn't restrict this

obj.someFunction();

  The first line clearly breaks the privacy contract, but with the second
line it's not so obvious anymore. It's calling a public member of _InnerClass,
but it's intended to be "public" only for OuterClass (because _InnerClass is
part of the private implementation of OuterClass), not for anything else.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   But an outside code could do something along the lines of:
> 
> OuterClass::_InnerClass obj; // Assuming the compiler doesn't restrict this
> 
> obj.someFunction();

That's correct. And no, the compiler doesn't restrict it. I don't know I've 
even heard of a source code tool that warns you about it, altho that would 
seem fairly easy to write, methinks.

Just FYI, the syntax for that would be
   obj = OuterClass._InnerClass()
   obj.someFunction()

OuterClass._InnerClass returns the class itself, since the class is just 
assigned as the value of the variable. Invoking that value with () does the 
equivalent of C++'s "new". Then you assign whatever the constructor returned 
to obj.  Depending on the existence of different functions inside the 
_InnerClass class, you get things like overridden "new" or overridden 
constructors.

And, technically, a constructor doesn't *have* to return an instance of the 
class you invoked, if you override "new" in the class and have it return 
something of a different class. So it's even uglier. :-) Just calling
   obj = OuterClass()
could actually wind up assigning an OuterClass._InnerClass instance to obj.
Handy for factory functions, tho.

>   The first line clearly breaks the privacy contract, but with the second
> line it's not so obvious anymore.

Correct.

On the other hand, it's the same result as if you did something like
obj = OuterClass::factory_method(...)
and factory_method returns an instance of _InnerClass. So it's not really 
something you could enforce there at the compiler level.  (As in, it would 
be hard to enforce at the obj.someFunction() call, but easier at the 
OuterClass._InnerClass access.)

I.e., I'm not sure I'd describe the second line as breaking the privacy 
contract. It's just using a value obtained by breaking the privacy contract. 
But that's just a matter of wording, really.

> It's calling a public member of _InnerClass,
> but it's intended to be "public" only for OuterClass 

Not necessarily. If OuterClass returns an instance of _InnerClass (like, if 
OuterClass is a collection and _InnerClass is an iterator over the 
collection) it might make sense.

> (because _InnerClass is
> part of the private implementation of OuterClass), not for anything else.

If OuterClass never returns instances of _InnerClass, yes, that would be a 
difficult violation of modularity to track down. It's certainly not the best 
way of doing things if you're worried about that sort of thing.

-- 
   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 wrote:
> It's certainly not 
> the best way of doing things if you're worried about that sort of thing.

Um, "it" there means "Python's way of handling private variables", not 
"inner classes".  As in, naming conventions aren't the best way of handling 
private members if you're worried about someone violating the privacy.

-- 
   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:
>   And it's getting really tiresome and old that you act all innocent after
> a tirade of C++ bashing, 

Can you do me a favor, for the sake of future conversations?

Can you tell me what I said that you took to be "a tirade of C++ bashing"?

As far as I can see, I've been trying to be factual and honest. You started 
out using derogatory terms like "it's a kludge", and "that's BS", and 
referring to people as "self-taught hackers" and "use a fancy term instead 
of admitting their mistake" and "In Utopia, maybe" and the usual insulting 
hyperbole.

Where did I say anything derogatory about C++? I would like to know what I 
said about C++ that you took to be saying C++ is *bad*. Can you actually 
quote what I wrote that you took to be "C++ bashing", let alone a "tirade"?

As far as I can see, the conversation (once it got to be about modularity 
instead of minimalism) went something like
You: "Modularity is good. Breaking modularity is bad."
Me: "Yes. But everyone breaks modularity in different ways.
    CLOS breaks it by doing A
    C# and Java breaks it by doing B
    Python breaks it by doing C
    C++ breaks it by doing D
    I prefer B over D."
You: "D doesn't count. C++ doesn't break modularity."
Me: "Wild pointers."
You: "Doesn't count - not standard."
Me: "Memset"
You: "Doesn't count - non portable."
Me: "But it still happens."
You: "You're so mean, always bashing C++."

So, in all honestly, I'd really like to know where in the process I said 
something that "bashed" C++, rather than simply comparing its behavior with 
other languages and explaining (in detail) why I preferred the other mechanisms.

-- 
   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:
>   You can't access the private variable by address. Not according to the
> standard. 

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf
Section 3.9 paragraph 2, page 60 sheet 74.

#define N sizeof(T)
char buf[N];
T obj ; // obj initialized to its original value
std::memcpy(buf, &obj, N); // between these two calls to std::memcpy,
                            // obj might be modified
std::memcpy(&obj, buf, N); // at this point, each subobject of obj of scalar 
type
// holds its original value


Yet I'm sure at this point that there will be some reason this doesn't count 
as violating modularity. Will it be that it's only a draft of the standard? 
Will it be that it's only true of POD types? Will it be because it only says 
it works for reading and writing all the private variables at once?

-- 
   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:
> >   You can't access the private variable by address. Not according to the
> > standard. 

> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf
> Section 3.9 paragraph 2, page 60 sheet 74.

> #define N sizeof(T)
> char buf[N];
> T obj ; // obj initialized to its original value
> std::memcpy(buf, &obj, N); // between these two calls to std::memcpy,
>                             // obj might be modified
> std::memcpy(&obj, buf, N); // at this point, each subobject of obj of scalar 
> type
> // holds its original value


> Yet I'm sure at this point that there will be some reason this doesn't count 
> as violating modularity. Will it be that it's only a draft of the standard? 
> Will it be that it's only true of POD types? Will it be because it only says 
> it works for reading and writing all the private variables at once?

  By the same logic this would also "break modularity":

T obj;
T obj2 = obj;

  All the data in obj is copied to obj2. This includes all the private data.

  However, the memcpy() version *is* breaking modularity because, as the
text says, it's guaranteed to work only if the object contains scalar
types. If you assume it does, you are breaking modularity.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Can you tell me what I said that you took to be "a tirade of C++ bashing"?

  A combination of concepts gave me the impression that you were
denigrating the way C++ does thing, while praising how other languages
do it better.

  Maybe you didn't use the word "unsafe" in a derogatory manner, but it
was easy to get the impression. When you said basically that it's not true
that C++ enforces modularity, and proceeded to "demonstrate" that by
trying to give examples of how you can circumvent C++'s semantics by
using low-level pointer casting and arithmetic, it gave the impression
that you were denigrating C++ for trying to do something and failing
miserably. This impression was emphasized by you at the same time telling
how you prefer how other languages do it "right" by having explicit support
for breaking the module interface boundaries, while in C++ you have to
resort to non-standard hacks to do the same. Also your arguments why
someone would even want to break the interface boundaries was not completely
convincing to me. (Your only argument seemed to be "reflection", and my
only experience on it is with Objective-C, where it's done without really
accessing private members from the outside, at least as far as I have had
to deal with it.) When you wrote that C++ is the only unsafe OO language
you know of, it sounded like you were bragging how *all* other OO languages
are better than C++, which gives the impression that you are telling that
C++ is the worst possible OO language in existence.

  I apologize if I overreacted.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   By the same logic this would also "break modularity":
> 
> T obj;
> T obj2 = obj;

Not really. operator= is declared in T.

>   All the data in obj is copied to obj2. This includes all the private data.

Only if you say that's how you want it to work.

>   However, the memcpy() version *is* breaking modularity because, as the
> text says, it's guaranteed to work only if the object contains scalar
> types. If you assume it does, you are breaking modularity.

You don't have to assume it does. You can read the header file and see it 
does. :-)

In any case, yes, you're breaking modularity. That's what we're saying, yes? 
Accessing private variables without the permission of the class breaks 
modularity?  Accessing private variables by address in a 
standards-conforming way breaks modularity. Given that you're agreeing with 
me, I'm not sure what the "however" in your sentence is supposed to imply.

-- 
   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:
> Darren New <dne### [at] sanrrcom> wrote:
>> Can you tell me what I said that you took to be "a tirade of C++ bashing"?
> 
>   A combination of concepts gave me the impression that you were
> denigrating the way C++ does thing, while praising how other languages
> do it better.

OK. As I said, I simply said I prefer how the other languages break 
modularity instead, and then I listed the reasons. "Bashing" to me implies 
denegrating it either by lying about its capabilities or saying it's bad for 
no reason or using abusive language or something like that, yes?

And yes, I was saying I prefer how other languages do it to how C++ does it, 
and I listed the reasons why. We all know why C++ does things the way it 
does, and the benefits that provides to the programmer. That doesn't make it 
"C++ bashing." If anything, the bashing was of Java in the original post.

>   Maybe you didn't use the word "unsafe" in a derogatory manner, but it
> was easy to get the impression.

I think you're oversensitive about that. I don't like unsafe languages for 
the reasons I've stated, but I don't know how saying that is "derogatory". I 
said "C is unsafe", I didn't say "C is a fucked up steaming hack pile of 
garbage whose inventors should be shot for being so stupid."  *That* is 
derogatory.

> When you said basically that it's not true
> that C++ enforces modularity, and proceeded to "demonstrate" that by
> trying to give examples of how you can circumvent C++'s semantics by
> using low-level pointer casting and arithmetic, it gave the impression
> that you were denigrating C++ for trying to do something and failing
> miserably.

OK. That wasn't the impression I was trying to convey. I was simply trying 
to point out that no unsafe language is truly modular, and the easier it is 
to find the unsafe operations, the easier it is to debug accidental breakage 
of modularity.

 > This impression was emphasized by you at the same time telling
> how you prefer how other languages do it "right" by having explicit support
> for breaking the module interface boundaries, while in C++ you have to
> resort to non-standard hacks to do the same.

You have to resort to non-standard hacks to *intentionally* break 
modularity, is what I said. And that there's two types of modularity involved.

> Also your arguments why
> someone would even want to break the interface boundaries was not completely
> convincing to me. (Your only argument seemed to be "reflection", and my
> only experience on it is with Objective-C, where it's done without really
> accessing private members from the outside, at least as far as I have had
> to deal with it.)

It doesn't happen really often, which is why I thought *you* were 
overreacting by calling CLOS a kludge OO system simply because you can break 
modularity by reading the source of the module. :-)

> When you wrote that C++ is the only unsafe OO language
> you know of, it sounded like you were bragging how *all* other OO languages
> are better than C++, which gives the impression that you are telling that
> C++ is the worst possible OO language in existence.

I said that because you challenged me to say which I'm talking about. By 
then, you were already convinced I had to be bashing C++ and I was trying to 
hide it after the fact. :-)

>   I apologize if I overreacted.

Apology accepted. I believe you did. I admit I've bashed C++ in the past in 
some ways, so it's not unreasonable, but I've been trying not to do that for 
quite some time now. It's primarily you teaching me about the power of it in 
conversations like this that has made me appreciate for what it is.

It's actually not that bad a language if it's the sort of language you need. 
I disagree with the design principles, and sometimes I explain why I 
disagree with them, but that's an opinion that everyone can feel free to 
decide for themselves. It's kind of funky how much power it can manage to 
build onto itself using what it comes with.

I'll try to be even *more* careful how I talk about things if you'll do me 
the favor that, when you get annoyed, you re-read without assuming I'm 
bashing and see if it still sounds like I'm "bashing."

-- 
   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:
> In any case, yes, you're breaking modularity. That's what we're saying, yes? 
> Accessing private variables without the permission of the class breaks 
> modularity?  Accessing private variables by address in a 
> standards-conforming way breaks modularity. Given that you're agreeing with 
> me, I'm not sure what the "however" in your sentence is supposed to imply.

  The breaking of modularity in this case has little to do with accessing
private members, and more to do with bypassing the normal copy constructor
or assignment operator semantics through reinterpret-casting pointers.

  "a = b;" and "memcpy(&a, &b, sizeof(a));" might in fact produce almost,
if not exactly identical machine code by the compiler, if the class in
question only has scalar types as members (and doesn't define an assignment
operator the compiler cannot see at this point). Thus at machine code
level the two expressions might in fact be completely identical.

  With this I mean that with the memcpy() you are not accessing the private
members any more than you are with "a = b;". They are both copying the
state of the entire object to another instance. You could say that with
memcpy() you still don't know *what* you are copying (what type of members,
how they are padded inside the class, etc), only that you are copying
everything verbatim.

  The difference, and what makes the memcpy() version non-modular, is that
the memcpy() version bypasses the normal class assignment semantics and
instead goes to the "raw hardware level". If the class would need a more
complex copying semantics than a bit-by-bit copy, then the copy is broken.

  I understand your argument to be that memcpy() could be used in this
way to *access* the private members of the object. However, it can't,
not in a portable way anyways, because you still can't know the internal
structure the compiler has generated for the class, and you can't point
to individual private elements.

  Perhaps this could be compared to calling the CopyFile() function of
the Windows API: Even though it copies the entire contents of a file to
another file, I'm still not *accessing* the contents of the file with
that function in my program. I'm just telling the system to copy it.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> OK. As I said, I simply said I prefer how the other languages break 
> modularity instead, and then I listed the reasons. "Bashing" to me implies 
> denegrating it either by lying about its capabilities or saying it's bad for 
> no reason or using abusive language or something like that, yes?

  I understand that "bashing" can also be used to describe overly negative
critique of something in a way that, while not telling any lies per se,
makes it sound a lot worse than it really is. Especially if the impact of
many of these negative things is exaggerated, and especifally if all this
is done on purpose.

  For example, in my "I hate Java" page I'm outright bashing Java because
I'm pointing everything that I consider negative about it, without pointing
out anything positive to compensate (although Java does have its positive
things as well). Someone who didn't know anything about Java could get a
rather biased impression of the language by reading that page alone. (Guess
twice if I care. ;) )

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I understand that "bashing" can also be used to describe overly negative
> critique of something in a way that, while not telling any lies per se,
> makes it sound a lot worse than it really is. 

Fair enough. I thought we'd already talked to death the advantages of unsafe 
languages (primarily performance and control).

> Especially if the impact of
> many of these negative things is exaggerated, 

I think you underestimate how much of a problem some problems are for 
average programmers because you've become expert.  I still occasionally get 
questions from people who have been programming for decades who ask
   "How do I debug something when it stops crashing after I add a printf()?"

You yourself have posted C++ code with a quiz-like "what's wrong with this 
class".  Clearly it takes a fair amount of expertise to write correct C++ 
code, doesn't it?

I can write C code that doesn't have bugs due to the unsafeness, but it 
takes me much longer because I have to think a lot harder about the 
boundaries. It's also something that took years of experience to learn.

I also figured it wouldn't be taken to be "bashing C++" if I pointed out the 
equivalent flaws in the whole list of other languages we were talking about, 
which is what led me to believe you might be a bit oversensitive or 
oversensitized.

>   For example, in my "I hate Java" page I'm outright bashing Java because
> I'm pointing everything that I consider negative about it, without pointing
> out anything positive to compensate (although Java does have its positive
> things as well). Someone who didn't know anything about Java could get a
> rather biased impression of the language by reading that page alone. (Guess
> twice if I care. ;) )

There's nothing wrong IMO with a good bash so labeled. I don't think 
anyone's going to read a page labeled "I hate Java" and expect a balanced 
presentation, any more than they're going to go to apple.com to see the pros 
vs cons of apples vs windows, say. I even think something like the C++ FQA 
is a valuable service, bashing as it is. I wish there were pages like that 
for every language and tool.

I don't think it's a bash of any one language to say "no language strictly 
enforces modularity, they're all broken in various ways, and here they are: 
...."  I'm hoping it's not considered bashing Y to say "I like X better than 
Y because ..."  It's not like I started talking about the flaws I think are 
in the design of C++ that haven't anything to do with violating modularity, 
or that I argued you can't violate modularity in the other languages.

-- 
   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:
>   With this I mean that with the memcpy() you are not accessing the private
> members any more than you are with "a = b;".

I would disagree for the following reason:

Altho {a = b;} *might* do the same thing as memcpy(), the author of the 
class has the ability to make it do something different, or to declare 
operator= to be private, preventing it altogether.

memcpy() can not be "defended against" in that sense.

"Can I change the values of private variables without invoking a class 
method or friend function?"  "Yes."  I'd say that's breaking modularity.

I think at this point we each understand what the other is saying, and now 
we're just having an argument about whether to call it "really" unmodular or 
only "kinda" unmodular. :-)

> They are both copying the
> state of the entire object to another instance. You could say that with
> memcpy() you still don't know *what* you are copying (what type of members,
> how they are padded inside the class, etc), only that you are copying
> everything verbatim.

Note, too, that even in this case, if you change your pixel example to be 
HSV instead of RGB, the memcpy() approach still works for moving pixels 
around. :-)

>   The difference, and what makes the memcpy() version non-modular, is that
> the memcpy() version bypasses the normal class assignment semantics and
> instead goes to the "raw hardware level". If the class would need a more
> complex copying semantics than a bit-by-bit copy, then the copy is broken.

Sure. I'm just arguing that the ability to use memcpy() *is* non-modular. 
The fact that it breaks or is non-portable in some cases would not seem to 
counter that fact. It would just seem to say "it's a bad way of doing 
things." :-) Which we both agree with.

>   I understand your argument to be that memcpy() could be used in this
> way to *access* the private members of the object. However, it can't,
> not in a portable way anyways, because you still can't know the internal
> structure the compiler has generated for the class, and you can't point
> to individual private elements.

Agreed. Not that it's difficult to figure out. I can think of at least 3 
easy ways to figure out where individual variables are: 1) use a debugger, 
2) look at the generated asm code, 3) stick a friend function into the 
header that returns the offset of the private instance. None of those are 
particularly portable, except the last, assuming that adding a friend 
function declaration doesn't rearrange the actual structure members.

I agree it's a concern in CLOS that someone will read your source code and 
access the internals of your class by learning the names of private 
variables and then you'll have to support it. I also contend it's about the 
same level of concern that someone will look at your header file, see it's 
POD, and write code that uses memcpy() to move POD-structs around (perhaps 
to different address spaces or into files or something), and you'll wind up 
having to support that.  Neither is really common enough to worry about, and 
both are trivial to avoid if you can change the module you're talking about 
or avoid the need to do that altogether in the caller.

>   Perhaps this could be compared to calling the CopyFile() function of
> the Windows API: Even though it copies the entire contents of a file to
> another file, I'm still not *accessing* the contents of the file with
> that function in my program. I'm just telling the system to copy it.

Sure. And my comparison would be that "Anything you can call CopyFile() on, 
you can open and read and write, possibly messing up the program that uses 
the file, or possibly for the purpose of bypassing DRM."

-- 
   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:
>   I understand that "bashing" can also be used to describe overly negative
> critique of something 

Or, to just phrase it a different way, I've been actively and consciously 
attempting not to say bad things about C++ and to ensure whenever I point 
out a limitation I also point out the equivalent limitation in other 
languages. Yet you continue to fall back on "you're bashing C++ to annoy 
me", which is kind of discouraging.

-- 
   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 wrote:
> I agree it's a concern in CLOS that someone will read your source code 

Or, to phrase it a bit differently, I'll agree that using memset() or 
memcpy() to get to the entire instance opaquely *feels* qualitatively 
different than the sorts of access CLOS or Python allows.

On the other hand, it seems kind of similar to the sorts of things 
reflection allows.

Even in Python, I think there's two kinds of accesses:
    x = myinstance._myprivatevar
vs
    "iterate over all public and private variables of this instance
     and do XYZ with them."
They feel qualitatively different, with the latter feeling more like
reflection and the former feeling more like bad news, even though they
both stem from precisely the same language rules.



As an example you might be able to relate to, to see what I'm talking about, 
consider http://www.boost.org/doc/libs/1_38_0/libs/serialization/doc/index.html

Look at the "class gps_position" example. It has a pair of routines named 
"serialize" each of which lists the exact same variables in the routine as 
are in the class. With a reflection library, adding this sort of 
serialization would be done by having a mix-in multi-inheritance routine, 
and you wouldn't need to code that sort of body at all. Of course, there 
would likely be routines like "serialize everything" and "serialize all 
public members", as well as routines like "serialize everything but X and Y, 
and when you load back in from the archive, invoke fix_up() on the loaded 
instance to fix X and Y." So lots of uses of this sort of thing are done 
from within the class, just taking advantage of the fact that you *already* 
listed the names and types of the instance variables, so why do it again?

Yeah, you can use it to get to the insides of classes from outsides, but you 
kind of want that for your IDE and your debugger. :-) It's a lot of power, 
and IME not a whole lot of misuse.

-- 
   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:
> Or, to just phrase it a different way, I've been actively and consciously 
> attempting not to say bad things about C++ and to ensure whenever I point 
> out a limitation I also point out the equivalent limitation in other 
> languages. Yet you continue to fall back on "you're bashing C++ to annoy 
> me", which is kind of discouraging.

  I'll try to be less paranoid next time.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I'll try to be less paranoid next time.

Thank you. I appreciate it.  In return, feel free to say something early on 
if it sounds like I'm not making the effort. :-)

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