since I had a misconception of its use!). I will not contest your
point on what the right goal for CamelBones is. If it is primarily a
means for an Objective-C/Cocoa programmer to gain access to a
scripting language for particular functionality, which is entirely
sensible, then clearly I have my expectations wrong.
What you're describing is different from what I'm used to - but that doesn't mean that it's wrong. Perl's motto is, after all, "there's more than one way to do it."
Perhaps I am missing
something... I am not a UI programmer so its very likely I am... take
a situation where I need to add a variable checkboxes (with variable
text labels) to my UI depending on the user startup configuration. My
naive approach is to read the user config at application startup and
then generate the UI -- this is how I have done it in Perl/Tk in the
past (which again may not be the best way, either!).
Depending on the specific situation, that may actually turn out to be the best way. Never say "never!"
My point is simply that what you're describing usually isn't the *first* approach that most Cocoa developers would think of. Using code to create a GUI on the fly isn't done very often. But, it is possible - Interface Builder itself, for example, does exactly that to build a UI on the fly, then serialize it to a Xib/Nib archive, and it uses only public AppKit methods to do so.
But you're right - it may well be the first approach that a Perl developer would think of. I've always thought of CamelBones as providing an alternative language for Cocoa, for those occasions when Perl is a better fit than Objective-C. Perhaps I've been thinking too narrowly. Perhaps it could also provide an alternative, more "Perlish" approach, for those occasions when a more dynamic GUI is needed. It's an approach that's not very well-supported in "traditional" Cocoa, in any language.
The good news (for me) is that I have been intending to bite the
bullet and start learning Objective-C, so perhaps in the future I will
be able to return to CamelBones to call upon my Perl strengths from
I'd certainly encourage that - in my opinion, a programmer should learn as many languages as he or she can. After all, a carpenter who only knew how to use a hammer would be in trouble when it came time to cut a board!
That said, I hope you don't leave us entirely. Your ideas and feedback in this conversation are valuable, in large part precisely *because* they're so different than anything I'd have thought of on my own.