Re: Cocoa et al as HCI usability problem
Re: Cocoa et al as HCI usability problem
- Subject: Re: Cocoa et al as HCI usability problem
- From: "Sherm Pendley" <email@hidden>
- Date: Mon, 19 May 2008 15:26:27 -0400
On Mon, May 19, 2008 at 1:33 PM, Peter Duniho <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden