[MacRuby-devel] Hotcocoa design ethos [was Re: [feature request] open url in browser]

[Jordan K. Hubbard]

On Nov 9, 2008, at 7:13 AM, Eloy Duran wrote:

> I like the idea of HotCocoa, but it should not go too far, and this  
> is maybe taking it one step too far imo.
> The problem is that at some point you _will_ have to use real Cocoa,  
> because HotCocoa can't wrap everything.
> If you are frightened by the verbosity of this line of code, well  
> than working with edge cases in Cocoa will
> give you nightmares. Maybe this is actually not an edge case,  
> because a lot of people might use this method.
> But my point is that MacRuby & HotCocoa should not teach the users  
> how to _not_ use Cocoa, but simply provide
> shortcuts for the majority of simpler cases.

I'm glad you opened this discussion since I think HotCocoa is likely  
to undergo something of a prolonged identity crisis unless we decide  
fairly early on just what it's trying to achieve.

  To my way of thinking, if all HotCocoa does is provide "shortcuts"  
like Eloy is suggesting then we probably shouldn't even bother going  
further in the direction we're going since it's basically just a  
glorified macro pre-processor and we should be trying to define just  
how the "macros" (or "mappings") work, documenting the process of  
creating them, and providing just a few examples in order to  
illustrate how they can be used.  It would also be a reasonable  
assumption that these mappings should be tied to the application  
itself, not stored in some central location (as they are currently),  
since applications would be creating them on an individual basis in  
order to shortcut their own frequently used Cocoa idioms.  Sure, we  
might have some collection of reasonable "system mappings", but just  
as you wouldn't provide /bin/cpp with hundreds of canned macros for  
general purpose use, we would not take HotCocoa in any particularly  
complicated directions, it would really be about creating and  
supporting the notion of mappings.

That's assuming that all the value of HotCocoa is in the mapping  
creation and management process, of course.  Speaking just for myself,  
I don't see enough real value in going much further with HotCocoa if  
that's the objective.  The real value, as I see it, is in creating  
useful abstractions "above" Cocoa for simplifying complex or difficult- 
to-learn operations, like basic UI or higher-level graphics /  
animation primitives (think "Logo" if you need a point of  
comparison).  If that is our objective then we should make that clear,  
also deciding whether or not it's worth adding mappings for things  
like NSUrl and NSWorkspace if those classes are already fairly easy to  
use (and I don't know if they really are, I'm just continuing to use  
them as examples) since Eloy is right in saying that there' no point  
in "wrapping everything" - we have to focus on the high value/high  
reward targets if it's true convenience and rapid development we're  
aiming at.

So, which is it, guys?  A glorified macro pre-processor with enough  
canned macros to illustrate how to use the same approach in your own  
applications, or an attempt to simplify Cocoa programming where it  
genuinely cries out for simplification, hopefully also in cases which  
are commonly used enough to generate real bang-for-buck?

- Jordan