Design Element
Comment on "Cocoa Learning Curve"
by Blain — Jun 10

the static-type protection in ObjC seems surprisingly weak.

Yeah. The type-checking on ObjC is one level above (void *), in some ways, which has some advantages (Delegates and dynamic KVC are big wins). In truth, the class doesn't matter as much as functionality. If you check respondsToSelector:, does it really matter if it's a subclass, as long as it handles the right methods?

I love Cocoa, but the tutorials and books I've read provide little information on the subject.

I don't know about Obj-C 2.0, but it really does feel as defacto instead of any organization:

returns BOOL for success or failure

(NSError **) is passed so that an error can be returned.

NSException is another one, mostly for cancelling out of an event.

@try @throw @catch @finally - I haven't used these language-level things as much, and it doesn't look like Appkit uses them.

From the looks of things, methods returning a BOOL and being passed in an (NSError **) seems to be the way to go for minor things, and NSException for failed assertions and the like.

(As I was writing, I found this.)

As for init failures, I'd guess raise an exception, and return a nil for self.

Back to "Cocoa Learning Curve"
Design Element

Copyright © Scott Stevenson 2004-2015