On Mar 24, 2008, at 10:30 AM, colo wrote:
In Ruby GC just works dandy without thought. Why is it so different
in Cocoa Obj2.0?
Conceptually, it's not much different. In implementation, however,
they are two separate garbage collectors and they don't play well
together. The problem crops up when you try to mix the two using
RubyCococa in a single application.
Right now RubyCocoa allows you to work with Objective-C objects
through the Ruby interpreter and it uses retain/release mechanisms to
manage the life-cycle of the Objective-C objects. To put it another
way, if you are using Ruby as your development language, you don't
have to worry about retain and release because the RubyCocoa library
does it for you.
However, that memory management is done in the RubyCocoa framework not
at the level of the Ruby garbage collector. The Ruby garbage collector
is not at all aware of the Objective-C garbage collector (and vice
versa). As a result, it might be possible for one garbage collector
to sweep away objects that the other garbage collector things should
be "live". That's not good.
To integrate the two, someone would have to rewrite the internals of
the Ruby interpreter and add in special case code for Objective-C
objects. That kind of a rewrite sounds Hard(tm) on many levels. Not
the least of which is the fact that interpreter is shared across many
platforms and environments and mucking with it's guts could have far-
reaching and unexpected consequences.
Regardless of the reasons, however, the fact remains that if you are
going to write a Cocoa application that uses the RubyCocoa bridge to
talk to some Ruby code in Leopard. The Cocoa application cannot use
the Objective-C 2.0 garbage collector.
What kinda of real headaches will I have jumping into osx programing
compared to ruby ?
It kinda depends on what you mean by "OS X Programming".
Well, if you want to do "Pure" Ruby programming (including Rails) on
Mac OS X, I doubt you are likely to run into many headaches. For
everything I've tried, which I must admit is not much compared to
what's possible, Ruby "just works" on Mac OS X.
If "OS X Programming" means writing Coco applications, then, the
RubyCocoa bridge will allow you write Cocoa applications in Ruby.
However, be forewarned that there are some headaches in integrating
the two. Those headaches might make learning Cocoa through Ruby
unattractive for the Cocoa novice. My opinion (and apparently the
opinions of others) is that you would be better off learning the Cocoa
framework through the Objective-C APIs first, and then applying that
knowledge to Ruby, than you would be trying to learn the Cocoa
framework through Ruby from square one. YMMV
If you are familiar with Cocoa and "familiar enough" with Ruby then
I've found RubyCocoa particularly useful in two instances:
1. Quickly prototyping some object designs. If I'm trying to put
together an object hierarchy or some object interactions, I will often
prototype them in Ruby and play with their interfaces and such (I used
to use Squeak/Smalltalk for that, but with ALL due respect to the
Squeak folks, Ruby takes up less screen real estate).
2. Exploring new APIs and new parts of Cocoa. I used Ruby to learn
some more about the Scripting Bridge and the "Publish and Subscribe"
frameworks. Mostly because I was curious about them. Again, the
ability to quickly throw together some... er... half-baked code in
Ruby and then poke at it with irb was pretty handy.
And to be fair, my understanding, though I have no experience with
these other languages, is that you can do the same thing with other
languages. Most notably, I've heard of support in FScript, Python,
Perl (by using CamelBones).
Does that answer your question?
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
