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.
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.
Re:WxPerl
Elian on 2002-02-02T19:02:50
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)
Re:Carbon
Elian on 2002-02-03T04:40:32
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...
