Errata

This is an error report NOT for ver 5.0 but rather Matt's new ver 6.0 which is currently only available on-line -- and there are no page numbers.

In Chapter 12, in the section labeled Property Accessor Synthesis is this paragraph:

Starting in the Xcode 4.2 application templates, Apple begin following a convention where a synthesized accessor would take advantage of the propertyName=ivarName syntax to give the instance variable a name different from that of the property in that the former was prefixed with an underscore. For example, the AppDelegate class?s implementation section contained this line:


////////////////////////////////
1) there's a grammatical error which should be corrected to read: "...Apple began..."
2) traditionally the underscore was associated with the ivarName not the propertyName, so I believe the text should read "...in that the later was prefixed with an underscore..."

Note from the Author or Editor:
You are right about begin -> began. Now fixed. Thanks!

You're wrong about which is former and which is latter. The sentence says "the instance variable ... different from ... the property ... the former was prefixed with an underscore". "Former" means the first of the two things I just mentioned, which is the instance variable - which is correct; that's the one prefixed with an underscore.

This error report is NOT for ver 5.0 but rather for Matt's new iOS 6 book which I believe is only available on-line. I couldn't find a report form for that edition.

So, below is the paragraph that precedes Code Example 12.10, and I believe Matt means to say "...at the top of the implementation (.m) file, before the implementation section." If I'm wrong about this then at the very least Matt means to say "...(.h) file"

Here's the current text:

To make a property declaration private, put it in a class extension (Chapter 10). Most commonly, the class extension will be at the top of the interface (.m) file, before the interface section. As a result, this class can use the property or call the accessors but other classes cannot (Example 12.10).

Note from the Author or Editor:
Excellent catch; now fixed.

"Call it MyLabel" comes one step too late (this dialog sequence must have changed when Xcode 4.2 came along). So, cut that from step 3, and now step 2 should start: "Call the new class MyLabel. Make it a subclass of UILabel."

Thanks to David Turetsky for wrangling this one.

" A C function is technically a kind of named variable, so you can even create a pointer to a function!"

Actually, as with arrays, it is not necessary to use the address operator with function names: K&R, 2nd Edition, 5.11 "Pointers To Functions", page119

Note from the Author or Editor:
This criticism is correct, and I need to modify the p. 172 code that illustrates (and look for any other place where I needlessly take a function's address - it does no harm, but it isn't necessary either). See http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/cross_development/Using/using.html on SDK-based development, which makes the same comment. This change is *not* going to happen for this edition of the book, but I have already modified the downloadable code examples at GitHub to eliminate unnecessary (but harmless) ampersand before the name of a function.

The second line of the first code example on the page reads:

float width = sc.bounds.width;

This should read:

float width = sc.bounds.size.width;

Note from the Author or Editor:
Page 572 in my copy. You're right, of course, and the reason this mistake happened is that in fact in my Zotz app I no longer use that code; I use the code on the next page! This mistake should be fixed in the next printing.

line 5 of the code example reads:

- ( void ) panning: ( UIPanGestureRecognizer * ) p {
...
CGPoint delta = [ p translationInView: v.superview ];

This should be:

CGPoint delta = [ p translationInView: vv.superview ];

Note from the Author or Editor:
p. 482 in my copy. Good catch. This mistake happened for a complicated reason: in my testing copy, there was also an ivar "v", pointing to the same view as "vv", so the code still compiled and worked, more or less accidentally.

The statement:

"Remember, though, that you can do this only if the class you're talking to has declared a property corresponding to the accessor methods in question."

isn't correct. It may be good form to use property syntax only for declared properties, but you can use property syntax anytime.

Similarly, on page 95, the statement:

"That's how I knew I could use property syntax as a way of calling a setter method"

also implies property syntax is limited to properties. Any setter method can be called with property syntax. In fact, any method without arguments can be called with property syntax:

NSString *s = @"Hello";
NSLog(@"Bad form, but works: %@", s.uppercaseString);

Note from the Author or Editor:
Yes, I've thought about this and whether it should go into the book, and it seems to me that it should not. It is true that you can say s.uppercaseString and I've done it myself, but the fact that this is possible is effectively a linguistic bug. Let's leave this note here as a reminder, but I'm not going to take any action for this edition.