[MacRuby-devel] HotCocoa Part I

[Rich Morin]

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     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development