Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Elian (119)

  (email not shown publicly)
AOL IM: DanSugalski (Add Buddy, Send Message)

Perl 6/Parrot internals ex-design team lead.

Journal of Elian (119)

Saturday February 02, 2002
10:54 AM

This Objective-C thing is kind of neat

[ #2601 ]

I've got an OS X machine as my primary box at the moment. While it's not the snappiest thing on the planet (it's an old 233MHz G3) but it works, and works pretty well. OS X even ships with perl, which is really nice. And some day, if FedEx stops taunting me, I may even have a shiny new iBook.

What it's missing, of course, is access to the graphics libraries and such. Sure I could install Tk, but... Yuck. Nick has done a great job of making Tk available from within perl, but there's not much he can do for the way it looks.

That means I need an interface to the native OS X libraries. I suppose I could write a Carbon interface. Carbon's the old-style procedural interface, basically the original Mac libraries cleaned up and trimmed to fit Apple's needs. Nice enough, but definitely legacy. It's really clear that Apple is doing this because they have to, not because it's strategic, or the direction they're going. That way lies Cocoa.

Now, Cocoa's nice. The tools that come with it--Interface Builder and Project Builder--are pretty sweet. Unfortunately Cocoa's OO. Completely. It's either Objective C or Java. (Three guesses which one I'm not going to use)

Turns out the ObjC is darned near as flexible as perl is. Want to call a method with just an ASCII string for a name? Sure, go for it. Reference a class by name? Can do that too. In fact, the entirety of the Objective C interface to Cocoa can be summed up in a single really evil (but short!) ObjC function. That's it. Everything else--proper class blessing and up-front error checking of parameter types--can be done in perl, and data driven at that.

All I need to do is write the interface to the *non* object functions (there are a few dozen), build the data files, get the housekeeping code written, and deal with the callback wedges.

Access to the 200+ Cocoa classes (Foundation and AppKit) boiled down to a few dozen lines of ObjC and another few dozen of perl. May turn out that abusing MakeMaker and gteting the convenience bits written is the toughest part of the whole project.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I don't know what the status is currently, by I know that WxWindows should normally run well on OS X and that it supposedly has a very native look (it certainly does under KDE and win2k). WxPerl itself is a really nifty toolkit as well. Not to drag you away from what appears to be pleasureable coding in ObjC, but you might want to take a look at WxPerl.


    -- Robin Berjon []

    • I have need of Cocoa support particularly, so WxPerl's not what I need. (Google can't find much mention of it, at least not OS X specific mention. The bits I can find are all very tentative)
  • I consider Carbon and Mac OS about as legacy as I consider perl 5. :-)

    However, yeah, Objective C is pretty darn cool in its flexible dynamic stuff. When doing Java shims for Cocoa they had to map out every little thing beforehand; not so for Perl!
    • Well, as the perl 6 gust sketcher (Now there's a good title for the business card), I do tend to look forward. Keep tripping over all these durned things in front of the horizon, though. :)

      I've half a mind to implement this for perl 6 at the same time as perl 5. That'd mean finishing the scratchpads, method call code, and AUTOLOAD. Not, mind, that this would be a bad idea...
  • I made this [] which made an Apple engineer give this response [].


    -- ask bjoern hansen [], !try; do();