A better introduction to Objective-C (cocoadevcentral.com)

Protocols are "interfaces" (in the general sense of the word in programming). So they are useful when you want to write a delegate (or callbacks in the general sense of the word) class. Many classes have a delegate property that is of type id<SomeProtocol>. Equivalent to Java's interfaces, but Cocoa use protocols heavily for delegates only.

Categories are useful not for sharing code, but for expanding a class's functionality. This is especially useful when you write a class X that works with an existing class Y, but some of X's code should be an instance method of Y, or X introduces additional capability for Y to support X. UITableView adding functionality to NSIndexPath to support referencing table sections and rows is a good example. All those Java classes that add static methods to support existing Java classes, or if you used Smalltalk and added methods to existing classes, this is the equivalent.

Close.

A protocol says that an object can (and in some (but not all) cases, is required to) implement a given list of methods, leaving the implementation/the "how" up to the programmer. Think of protocols as being similar to interfaces in Java.

OTOH, A category says "in addition to the existing methods, this class will also, for sure, implement these additional methods — and here's how."

A protocol is an interface (a type contract), a category is a mixin (class extension)

I think people should not use awkward code in tutorials and then say it was for the sake of illustrating a point. Otherwise the readers can pick up bad idioms just as in a natural language. In this case I doubt the author wanted to showcase YES/NO. And if that really was the intention, you can easily add one sentence after the code example, explaining the potentially strange BOOL type and its values.

I think that it teaches that conditionals (or boolean constants) are "special". When I first learned to program I did similar things, and I think it held the "everything clicks" moment back.

Please note that you still can't ship an app that uses Automatic Reference Counting on iOS, and we don't have any real idea of when we will be able to. Last time I had a discussion about this on HN, the other person was convinced it would have come out early September.

Or even (granted that I'm assuming the whole db api here is fake, and you'd actually probably be using core data here)

  NSArray *records = [[db find:[NSDictionary dictionaryWithObject:@"Joe" forKey:@"name"] limit:10]
                       sortedArrayUsingComparitor:^(id a, id b) {
                         // sort logic
                       }];

I typically add a category to NSArray for mapping a selector or block. The signatures are - (NSArray )mapBlock:(id (^)(id object))block; - (NSArray )mapSel:(SEL)selector;

Which would enable you to do it all in one statament:

  NSArray *records = [[[db find:[NSDictionary dictionaryWithObject:@"Joe" forKey:@"name"] 
                       limit:10]
                       sortedArrayUsingComparitor:^(id a, id b) {
                         // sort logic
                       }]
                       mapSel:@selector(lowercaseString)];

Also for mapping over an array you can usually use NSArrays valueForKey: which returns a new array which contains the result of calling valueForKey: on each member of the target array. As your sorting logic would typically exist in the db layer whether you were using CoreData or something else, it would be easy to write a wrapper such that you could write something like:

  [[[[MyFetchRequest forEntityNamed:@"foo"
          orderedBy:@"SomeKey"
          limit:10] fetch]
    valueForKey@"nameField.lowerCaseString"]
    enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
       // do stuff here
    }];

Again this is all 'fake' code as this is just a readability discussion.

I don't really agree with the article that nesting message-sends leads to unreadable code. I think reading obj-c is a lot like reading lisp s-expressions and your eye / brain quickly learns to read nested constructs. I generally try not to save anything to an explicit var that I don't intend to use somehow. (of course there are limits to this) I don't find nested code above difficult to read, YMMV.

If you have an observer listening for changes on the "photographer" key, then `self.photographer = nil;` will send off a KVO event. [photographer release]; will not.

Since your object is likely to be dealloced at an odd time (for instance when an autorelease pool is drained), and in an inconsistent state (half its fields missing), it's much better to do a release.

  - (void)dealloc {
    self.someOtherVariable = nil;
    self.myC = nil; // Sends KVO on myC. B sees half-deconstructed A.
    self.myB = nil; // myB now is dealloc'd and stops observing A.
    [super dealloc];
  }