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