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

[Brian H. <bri...@py...>]

> 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 (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').

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

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.

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

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.

Brian