[MacRuby-devel] HotCocoa Part I

[John Shea]

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     rdm at cfcl.com
> http://www.cfcl.com/rdm/weblog     +1 650-873-7841
>
> Technical editing and writing, programming, and web development
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel