Design Element
Comment on "Objective-C, Ruby and Python for Cocoa"
by Scott Stevenson — Feb 20
@Ryan Brown: Here is a before and after with your example code
It's certainly more clear which argument goes with which value, but I don't think it's as readable as Objective-C's named parameters.

Second, why are you (and all the other Mac bloggers) talking like these bridges are something new
A lot of it started up because of John Gruber's interview, but the fact that they will be bundled with Leopard increases their visibility. A lot of people may have not known about them before.

Another thing I forgot to mention is the issue of interpreter versions. The PyObjC project I was working on had its own version of Python in the application package in. I'm not sure what the exact reason is for that, but I wonder if it will be negated by Leopard.

That document you linked to also has some interesting details about how to get access to C functions. Apparently a metadata file is generated for each framework which gets interpreted at runtime. It looks like they're tackling one built-in framework at a time, but I'm not sure how third party code is handled. This is all exciting stuff, though, even as a great tool in a larger toobox.

Also, this seems to have some, um, interesting implications:
class NSString def length 42 end end # Now, all NSString objects will have a length of 42

The plain text aspect of this is what strikes me. Developers who have an Objective-C app which allows RubyCocoa plug-ins to load (or even just RubyCocoa code in the bundle) might have something to think about here.
Back to "Objective-C, Ruby and Python for Cocoa"
Design Element

Copyright © Scott Stevenson 2004-2015