Linked by Jared White on Thu 24th Apr 2003 17:49 UTC
General Development There are two major varieties of Cocoa available. The first variety, possibly the more well known of the two, is the kind that you can use to make a nice warm cup of chocolate milk. While tasty, it's hardly proper subject matter for an operating systems information site. The second variety is far more on-topic: a programming environment for Apple Mac OS X that is the modern evolution of of the original NeXTSTEP frameworks. That's what I'm here to talk about today.
Permalink for comment
To read all comments associated with this story, please click here.

How then do you figure out if you've made such a programming error? I've seen such things happen in C++ in UNIX, but the consequences aren't good and very hard to track down.

Use NSAssert and check whether object is nil or not.

What happens then if I manage to call a method on an object that doesn't support it?

You will/may get an exception that 'instance of Foo does not respond to selector bar' or similar.

To be honest, I don't know a whole hell of a lot about autoreleasepools or whatever they're called, so that might solve some of this problem.

It does. In ObjC you do not have to worry (too much) about garbage collection.

Well, I remembered the object initialization process for Objective-C requiring two methods, but I guess I'm wrong.

You can use
NSData *data = [[NSData alloc] init];
NSData *data = [NSData new];

Same thing, though the latter is considered bad style.

As far as naming parameters being easier, not only do you have to remember their order, you also have to remember their name, unless you have a reference for the class you're using, and then the point is moot.

That is true, however, [foo containsObject: bar]; is easier to read and (well, not necessarily in this example) understand.