Hello,
I'm the Apple engineer that owns PerlObjCBridge, which is the Perl <=>
Objective-C bridge that was discussed recently on this list. Yesterday
someone forwarded me the information about the petition to get this
technology released outside Apple, so I joined this list this morning
and poked around a bit in the list archives. I'll try to address some
of the questions that have been asked and maybe clear up some possible
misconceptions about what PerlObjCBridge does and does not do, and what
the prospects are for getting it released outside Apple.
I created PerlObjCBridge purely as support technology for my main area
of development, which is the Mac OS X build system XBS. XBS contains a
lot of Perl and uses PerlObjCBridge to access Obj-C objects in private
XBS frameworks and in Foundation. Since building and releasing Mac OS X
depends on PerlObjCBridge I've had to make sure that it is reliable in
the ways in which we depend on it. On the other hand, I have almost no
experience in using it to create Cocoa applications, so I cannot vouch
that it works in that arena, although in theory it should or could.
Here's what it does:
- You can create and message Objective-C objects from Perl, e.g.:
use Foundation;
# print Hello World
$s1 = NSString->stringWithCString_("Hello ");
$s2 = NSString->alloc()->initWithCString_("World");
$s3 = $s1->stringByAppendingString_($s2);
printf "%s\n", $s3->cString();
# get value of Foo property from plist
$path = NSString->stringWithCString_("/tmp/foo.plist");
$dict = NSDictionary->dictionaryWithContentsOfFile_($path);
$key = NSString->stringWithCString_("Foo")
$value = $dict->objectForKey_($key);
- You can create bridge modules to any dynamic library that contains
Objective-C (with the constraint that objects must descend from
Foundations's NSObject).
- It bridges Perl's garbage collection and Foundation's autorelease
memory management so that when Perl's refcount on an Obj-C object goes
to zero the Obj-C object gets released by the Obj-C runtime.
- NSExceptions are handled by the bridge and optionally forwarded to
user-defined Perl exception handlers.
- My experimental version supports messaging from Obj-C to Perl objects,
via a PerlProxy Obj-C class that wraps the Perl objects and forwards
messages to them. This allows Perl objects to be defined as "callback
objects" from Obj-C API's. For example, they can be used as delegates,
they can be registered to receive NSNotifications, etc. This also allows
them to be exported via Distributed Objects, so that you can write a
Perl server that exports a Server object that can be accessed by either
Perl or Obj-C clients via Distributed Objects. Similarly Obj-C server
objects can be accessed by Perl clients using DO. This mostly works
already, although there are a couple of gnarly issues still to be
resolved.
Here's what it doesn't do:
- It doesn't do straight C. It doesn't allow you to access Cocoa
functions, variables, typedefs, enums, #defines, etc. In other words, it
does none of the stuff that h2ph or h2xs do. It only allows access to
entities known to the Obj-C runtime system. This is good enough for
simple data processing, probably not good enough for general application
development.
- It doesn't do varargs style messaging (due to the fact that
NSInvocations don't support varargs messaging).
- It doesn't dynamically generate Perl packages when it loads Obj-C
dynamic libraries. Instead it statically creates bridge modules that
textually define Perl packages for Obj-C classes. Not very dynamic.
- Lots more stuff that I'm sure people would want.
So you can see that as a general mechanism for building Perl/Cocoa
applications it has a ways to go.
On the subject of why Apple hasn't released PerlObjCBridge, I'll bear
the blame for that. I have a one year old son and haven't had spare time
lately to get PerlObjCBridge in the kind of shape where I would feel
comfortable open sourcing it. But now that 10.0 and 10.1 are out the
door I have dusted it off, although it remains a background priority
task. The Darwin product manager has requested that it be added to
Darwin, and that will happen as soon as I have the time to get it ready.
I also hope that it will make it into the next major release of Mac OS
X, although management still needs to approve that. My plan is to get
the PerlProxy stuff in reasonable shape and then release it to Darwin
fairly soon. I will leave it to the open source community to make the
other improvements that people need for this to be generally useful for
application development.
Doug Wiebe
Lead Engineer / XBS
Apple Computer
