PerlObjCBridge

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

• PerlObjCBridge by Doug Wiebe
• Re: PerlObjCBridge by Bill Stephenson
• Re: PerlObjCBridge by Christian Jaeger