I think its interesting that Hot Cocoa in inspiring such different
ideas, I must admit my thoughts had not run anywhere as complex as
those below.
My first thought was "Wow! I can make a generic (or fairly static)
launcher and get it to load remotely both my view and model from ruby
files! Thats my RIA issue solved!"
I experimented and sure enough I could deliver to my client (me in
this experiment ;-) ) rapidly changing versions of a beautiful GUI app
(1 button) by only changing the source file on the server.
But maybe this is "old hat"?
J
On Dec 2, 2008, at 11:48 PM, Rich Morin wrote:
At 10:10 -0500 11/12/08, Richard Kilmer wrote:
"HotCocoa is an idiomatic Ruby API that simplifies the configuration
and wiring together of complex ObjC/Cocoa classes."
I realize this will not be all things to all people, and that some
may not see the much value in this. I do, and I think that HotCocoa
should NOT try and be all things to all people. Let me even get
more specific. I don't think that HotCocoa should strive to contain
simplifications for all frameworks in Cocoa.
If core audio needs to be simplified though a wonderful Ruby API
then it should be done with a wonderful Ruby API, but that is not
HotCocoa, its a core audio MacRuby library. Something that uses
HotCocoa could also use that wonderfully simplified core audio
library. To try and say every simplified use of ObjC frameworks is
included in HotCocoa creates a truly unwieldy beast.
It's clear that HC provides a lot of useful infrastructure for making
Cocoa programming more palatable to Rubyists. More to the point, it
makes it easy for developers to create even more useful
infrastructure.
A large part of HC's value lies in the fact that it's so easy to wrap
ObjC and Cocoa goo in nice Rubyish idioms. This encourages HC users
to
create frameworks as they go along. Encounter an obnoxious API,
write a
framework to wrap it, then get on with creating the app...
Consequently, IMHO, the question of whether HC _should_ include
zillions
of random frameworks is rather off the mark. Clearly, if HC becomes
even
slightly popular, community members _will_ be creating these
frameworks.
The critical question, then, is how to create an environment that
allows
(nay, encourages!) frameworks to be created, tested, polished,
documented,
indexed, shared, etc. My intuition is that GitHub should be part of
this,
because it promotes free-flowing cooperation, merging, etc.
However, I'm
quite sure that GitHub isn't the entire solution. So, ideas are
welcome!
-r
P.S.
One specific suggestion is that there should be a set of guidelines
for
framework creation. That is, how do I tell if I'm creating my
framework
in a manner that will be usable by other developers, similar in style,
etc? Some of this can be gleaned from perusal of the code, to be
sure,
but explicit guidelines can help to make things clearer...
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume [EMAIL PROTECTED]
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
