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

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

At 02:24 AM 12/27/2001 -0500, Patrick M Doane wrote:
>What happens to these messages that are not understood?

Run-time error.

>Are these messages simply ignored?  Does the recipient simply pass them on 
>to another more
>knowledgeable target? Or can the recipient decode the types and content of
>the message?

First off, the caller can verify that the message receiver understands the 
message:

if ( [obj respondsToSelector:@selector(someMessage)] )
    [obj someMessage];

Second, the recipient can optionally forward stuff.  Before the run-time 
system pukes because a message isn't understood, it will actually send 
another message, forwardInvocation:, to the message's target with an 
NSInvocation object, at which point you can try to recover or do something 
else appropriate.  In fact, the way the system pukes is it actually calls 
up to the default NSObject -forwardInvocation message which executes 
-doesNotRecognizeSelector.  So you can override this message and do the 
appropriate thing (like multiplex unknown messages to delegates).  That, to 
me, is very cool.

http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/5RunTime/Forwarding.html

>BTW, I'm curious to see something unbelievably powerful! :)

FWIW, I don't know Obj-C very well, at all.  The docs do a much better job 
at describing this.  I'm not a language lawyer by any means, I just happen 
to "click" with Obj-C much more than I do with other languages in terms of 
what feels intuitively right.

>When a language relies on inheritence for subtyping relationsips, then
>additional effort is required when an interface is created after a
>particular implementation is coded.

Can you give an example of this?

> > For example, some STL classes require operator < to be overloaded,
> > which goes back to a thread on another mailing list where I said that
> > function name overloading is a Bad Idea so long as you're using text
> > as your representation because you can't find, for example, every
> > place you're doing a comparison between two specific types.
>
>Don't virtual methods suffer from the same problem. or do you consider
>that another form of function name overloading?

Yes, virtual functions definitely suffer from the same problem, but in my 
experience the frequency of name collisions is much lower through 
inheritance than through function name overloading (either "real" 
overloading or just using the same names).

Brian