@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.
by Scott Stevenson — Feb 20
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 42The 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.