search

HotCocoa / hotcocoa

MacRuby HotCocoa UI library
120 stars 8 forks source link

Expand Mission Statement #44

Open isaac opened 12 years ago

isaac commented 12 years ago

That's good to know. It would also be good to know, if and when the subject ever comes up, what its mission statement currently is. Front-end all of AppKit? All of AppKit AND Foundation? Neither of those, but provide convenience functions if and only when a certain conciseness (as expressed in percentage of code saved) is achievable? This is something I have been wondering ever since Rich started the project, since it definitely achieves an admirable degree of brevity over the equivalent ObjC code, but where do you stop? How will we know when HotCocoa is "done"? :-)

http://lists.macosforge.org/pipermail/macruby-devel/2011-December/008456.html

ferrous26 commented 12 years ago

I just sent this to the mailing list:

Hi guys,

I think Isaac already answered things fairly well, but I still thought I would throw in my two cents. HotCocoa will be done when Cocoa is dead. Even then, I'm sure there will still be things to do.

The "goal" of HotCocoa, as I see it, is to make Cocoa apps easier to develop and maintain using MacRuby. The problem here is that that is an extremely broad goal. Everything that Isaac listed is currently aided by HotCocoa by using different components of the project.

Some of the components, like the mappings and delegate builder, were designed together and work together nicely; while components like the application builder are completely separate and could become a separate project under the HotCocoa banner in the future. Similarly, the fork of macruby_graphics that exists in the HotCocoa (as hotcocoa/graphics) should also become a subproject of HotCocoa in a different repository and released as its own gem.

"Do we want to front end all the AppKit classes?" No, not unless it can be justified, and I don't think it can. Also, while AppKit may have been the original motivation for mappings, any class in any framework can have a mapping added. Mappings are justified if they make using the class flow more nicely/succinctly with the rest of the code you write, or if it advantageous to get a feature like block based delegation. Even if a mapping would not be useful in general, you can still write it and load mappings yourself.

"...provide convenience functions if and only when a certain conciseness (as expressed in percentage of code saved) is achievable?" This is similar to what I said above, except it gives a specific heuristic, percentage of code saved, which I think is not quite accurate. It is about making things easier to code/understand/maintain, which isn't always the smallest amount of code. For instance, masking in HotCocoa is just an array of symbols which I think is a bit more verbose looking than a chain of XOR'd constants; though since the symbols don't include the Cocoa prefix (i.e. NSAnnoyingPrefix) it ends up looking shorter than the equivalent Objective-C code.

However, HotCocoa can't do everything for everyone with the amount of resources it has now. Personally I will be focusing on updating and strengthening the existing components. I haven't been able to give HotCocoa the love it deserves in the last few months as I was busy with school. That being said, I'm not the only person working on HotCocoa, and the project has been moving ahead thanks to other contributors. I won't be in school for the next few months, so I'll have more time for HotCocoa again.

We have plans to improve documentation and promote the project in the next year, and hopefully that will help answer these questions in better detail.

HTH, Mark Rada