Flutterby™! : wtfjs 2010-08-02 22:07:04.622993+00

wtfjs

2010-08-02 22:07:04.622993+00 by Dan Lyke 3 comments

I've been doing some Objective-C recently for Cocoa widgets. Mostly I get stuff in and out of NS objects as quickly as possible and do everything I can in C++ (so that I actually understand the memory model... yeesh!), but some of the hate leveled at OO in Meuon's JIT coding entry and the discussion about "coding ahead" has me thinking about some of the ways in which NeXT and then Apple have mixed "...all the memory safety of C combined with all the blazing speed of Smalltalk..." to be the core of their widget set, and how paradigms for coding have trade-offs.

With that in mind, I think wtfjs is a great resource for JavaScript and all its silliness.

If you ever decide to embrace the NS... ideology, Mike Ash has a bunch of good articles on Obj- C programming, complete with classes he's written to make things easier.

There's enough to like about the system that I've been thinking about heading the GNUstep direction for some of my personal apps. I guess memory mostly just works; as a general guideline retain/release only needs to happen if you hold the memory across the event loop boundary. Interface Builder is still annoying, right now I'm trying to figure out how to get an IBOutlet connected to an NSScrollView (that contains an NSOutlineView which I have no trouble getting to), and I really wish that the connections were made in code or in a list form somehow.

But I'm not ready to tie myself to Apple hardware generally, or OS/X at all, so I have trouble drinking the whole Cocoa-for-everything Flavor Aid.

For connecting the IBOutlet, change the dock window to list mode, twiddle the arrows (option-click to expand all of them at once) for the window, then control-drag and make the connection there.

If you're wanting to run on windows, Cocoatron is an active project. I'm in awe of the principal developer's tenacity. Nice guy, too.

You can make connections in code. -setTarget / -setAction is what is actually done under the hood. Messages to the first responder are actually setting the target to nil.

The memory rules boil down to: 1) if you get the object from new/copy/alloc, you own it 2) If you get the object from anywhere else, you don't own it

Then it's your responsibility to release it when done (case 1) or retain it if you need it to survive the current function (case 2). The Xcode static analyzer is good for catching most memory management thinkos.

It's a weird platform, but I've had more fun using it in the last 10 years then I had the previous 10 doing other stuff.