RE: [GD-General] Re: Simulating constrained genericity in C++

[Jesse J. <jes...@mi...>]

At 4:47 PM -0800 12/26/01, Brian Hook wrote:
>  > Maybe, but think about how you'd write generic code in a language
>>  like Smalltalk or Ruby. You'd use untyped objects and rely on the
>>  methods being present, just like you would with templates.
>
>Well, it's not quite THAT anarchistic.  In Java you could require that
>the objects conform to a specific interface; in Obj-C the objects would
>have to conform to a formal protocol; and in Eiffel they would have to
>be derived from the appropriate type

Which is why I was careful to say Smalltalk and Ruby. :-)

>(same goes for C++ -- my complaint
>here is that in C++ you're reinventing things like an ultimate "Object"
>class whereas this basic functionality is provided by other languages
>'natively').

Fundamentally C++ is just one great big hack. It's a pretty good 
hack, but when it comes to things like elegance it just can't compete 
with languages that were designed with less historical baggage.

>  > You're in good company with that argument. :-) I don't quite buy it
>>  myself. It's awfully nice to be able to create new types and have
>>  them behave like the primitive types (think point, vector, complex
>>  classes). It's even nicer if you can do this without incurring a big
>>  performance hit.
>
>Well, this is one of those few areas where I'm willing to agree to
>disagree =) I know some people, for example, hate having to remember
>separate "setFloatValue()" vs. "setIntValue()" vs. "setCharValue()"
>methods.  I'm one of those people that happens to hate having the wrong
>damn function called because of some implicit cast.  And, not to beat a
>dead horse, as long as I'm stuck fundamentally editing text, I'd like to
>be able to grep my source in a meaningful way.

Sure, but most people don't overload that many methods. Just stuff 
like the operators and an occasional named method now and then.

>Even my own frameworks still have lots of inadvertent name overloading.
>For example, I have HFile::create() which is completely and utterly
>unrelated to HAudioDevice::create(), but when I want to find every place
>I'm creating a file, I have to grep for "create(", which of course will
>give me "_create(" or "recreate(".  If I look for ".create(" I'll miss
>">create(".  And, of course, I'm going to find my "device->create("
>calls when I want my "file.create(" calls.
>
>Blech.
>
>This is where better tools would just really help a lot when trying to
>refactor source code.

Yeah, tools are just pitiful. It doesn't help matters that C++ is so 
damned hard to parse...

>  > might be right now, but I suspect it would include support for
>>  dynamic types and reflection.
>
>Well, that's the rather big bitch now.  The people designing languages
>often have these really focused philosophies:
>
>"You don't pay for what you don't use"
>"Everything is an object"
>"Static typing and design-by-contract reduce programmer error"
>"Dynamic typing and reflection are powerful"
>"Separate interface from implementation"
>
>Often they're incompatible philosophically, so the notion of adding
>reflection and dynamic typing to, say, C++ or Eiffel would cause those
>advocates to freak out that you're asking for "the wrong thing".  Sort
>of like asking Java people for pointer math.

Yup. It's kind of funny. What has it been? 50 years that people have 
been designing general purpose programming languages? And what have 
language designers come to agreement on? Goto's are bad? Even garbage 
collection still has a bad reputation in many places...

>Obj-C is probably the closest I've seen to a good compromise.  If you
>statically type something, the compiler will warn when you're pitching a
>message that the receiver won't understand.  But if you don't statically
>type it, you can use it however you want, and if ask the object what its
>class is and/or whether it recognizes a particular message.
>
>Damn brilliant language.

Yeah, I really need to look into Cocoa. I'm a bit put off though 
because it seems to be much more C-like than C++ if that makes any 
sense. :-)

   -- Jesse