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