What determines the process of solving unrealized methods?

Question

As I understand it, an unrealized method is solved as follows:

• resolveInstanceMethod: / resolveClassMethod: gets the opportunity to implement the method
• forwardingTargetForSelector: gets the option to send to the delegate
• forwardInvocation: gets the ability to process the method as it sees fit.

Where is this three-step process determined? I would like to handle this myself, since NSInvocation may be too heavy for my needs. I had a signal from a runtime source and can't see anything.

It looks like the old runtime will cause a redirect: args: on the receiver to do this, but it seems to have gone away with the new one. I assume that the process should be determined by the framework, and not the runtime, since it would be strange if the runtime depended on Cocoa to the extent that NSInvocation was required to process messages. Perhaps this is an undocumented method called in NSObject / NSProxy?

Edit:

It looks like the runtime declares, but never defines, a C function that is called when objc_msgSend cannot find an implementation:

id objc_msgForward(id object,SEL message,...);

I do not work for Apple, so I do not know how Foundation implements this, but at least in the case of Cocotron, they use:

 id objc_msgForward(id object,SEL message,...) { Class class=object->isa; struct objc_method *method; void *arguments=&object; if((method=class_getInstanceMethod(class,@selector(forwardSelector:arguments:)))!=NULL) return method->method_imp(object,@selector(forwardSelector:arguments:),message,arguments); else { OBJCRaiseException("OBJCDoesNotRecognizeSelector","%c[%s %s(%d)]", class_isMetaClass(class) ? '+' : '-', class->name,sel_getName(message),message); return nil; } } 

adding forwardSelector:arguments: method doesn't seem to work, so I assume this is Cocotron specific. Does anyone know what objc_msgForward does in Foundation?

Answer 1

I am writing something like a scripting language using the message forward to interface with objective-c. While I use NSInvocation, but it can end up doing it thousands of times in a second, so the overhead will be noticeable. But I think I'm just curious ...

As for message forwarding, the behavior is [often subtle] different from different platforms and runtime versions.

In any case, do not reinvent the wheel. Today there are two language bridges that are very close to a full bridge, from which you can learn a ton. Both have liberal licenses specifically designed for such reuse.

In particular, the MacRuby project offers a Ruby implementation that sits on top of the CoreFoundation and Objective-C garbage collectors. This is the "most native" bridge available (and not terribly tolerated as a result - not the goal of the project).

The PyObjC bridge is the best example available for a high-precision bridge between the Objective-C runtime and another OO dynamic OSE; Python It's a bit more portable, though bits other than Mac OS X are most likely rotted.

(I would refuse to mention F-Script, a new language built on Objective-C, for which, in my opinion, the source is / was available?)

All bridges deal with method forwarding, subclassing, and pass-through proxies, all of which sound as if they are applicable to your specific needs.