This article was published on Wednesday, December 12th, 2007 at 10:58 pm.
RubyCocoa parses Cocoa methods that return multiple values through pointer parameters! Check it out:
>> NSWorkspace.sharedWorkspace.getFileSystemInfoForPath_
isRemovable_isWritable_isUnmountable_description_
type_("/Volumes/SparkleCaster/English.lproj")
=> [true, 1, 0, 1, #<NSCFString "hfs">, #<NSCFString "hfs">]
Now we’ve just got to do something about that really ugly method name…
Hi there. I'm Andy Matuschak, a computer science student at Caltech, but a software engineer at heart. I'm a long-time Cocoa programmer and a user experience nutcase and all that—you can read about what I've done or what I'm working on elsewhere.
I do have an untechy side, too. I'm a singer first and foremost, a passable pianist, and a okay-maybe-needs-more-experience actor. I love to teach. I love to write. But most of all, I'm quite helplessly in love with life.
Questions? Comments? Feel free to reach me by email or by AIM. I'll do my best to get back to you rapidly, but Caltech is a cruel mistress.
If you're looking for something specific then give the search form below a try:
The Conversation {2 comments}
I think there’s always going to be a disconnect between non-Objective-C interfaces to Cocoa for exactly this reason (the message-passing syntax). You can paper over it with dictionary-style name/value mapping, etc., but it’ll never be as good as the original.
That’s why I’m off designing a new dynamic language that exactly matches Objective-C’s syntax & general semantics…
Ohman, another one?
I like Nu in theory, but native arrays and hashes are important to me and, well, I find myself having a lot of trouble keeping a sense of scope in big s-exprs.
But yeah, there will always be some level of disconnect. Unless… maybe Ruby 2.0’s named parameters will help.
Leave a Comment
You can follow any responses to this entry via its RSS comments feed. You can also leave a trackback if the inclination is there.