On Mon, May 19, 2008 at 1:33 PM, Peter Duniho <[EMAIL PROTECTED]> wrote:
Well, I'm still waiting for someone to show me how that flexibility is used. I'll take that challenge. :-) The flexibility of the Objective-C language & runtime allow me to intercept messages sent in either direction, and route them through a "bridge" function that translates them to a foreign language. In this case, the language is Perl, but I don't intend to brag here - as I understand it, the Ruby and Python bridges have similar capabilities. Because Perl is dynamic, I can create a "default" method that intercepts any unknown messages. This Perl method passes the class and method names as string arguments, and that's exactly what the runtime functions take. Once I've queried the runtime to find the correct Class and Sel structures to use, and a description of arguments and return types, the rest is a SMOP - using libffi to build a stack frame and make the call to the message dispatch function. A similar process happens in reverse. Perl classes can be registered with the Objective-C runtime. The IMP (implementation function) for any method that's implemented in Perl is the same - a single dispatch method I've written that examines the "self" and "_sel" arguments, and dispatches the call to the appropriate Perl method. Because both Perl and Objective-C are dynamic, I wrote a single "bridge" function for each direction, and that's all I needed to write to support calling any method on any class, whether it's known at compile time or not. That's the easy stuff. :-) You can also create an Objective-C subclass of a Perl super class. You'll need to create a header with an @interface for the Perl class, and you'll get a warning when compiling it because there's no @implementation available at compile time. But, if your subclass is defined in a bundle and loaded dynamically after the Perl superclass has been compiled and registered with the runtime, the runtime sorts out the inheritance correctly when the subclass is loaded - because the superclass is registered dynamically, by name. As I understand it, the Python bridge (and maybe others) has an "injector" feature that allows you to inject a Python interpreter and command console into any Cocoa app, while the app is running, whether the app was built with them not. Since everything is dynamic, you can look around and manipulate objects and properties by name. In essence, you can add a plugin interface to an app - whether it wants one or not. :-) Note that I'm not trying to say these kinds of things *can't* be done in C++ or Java. I'm just saying that, to support things like the ability to refer to random (possibly unknown) methods and properties, by name, would require a lot more work to implement in C++ or Java. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
