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