[JFischel]

Does anyone have this book? I have the Learning Cocoa book, and I was thinking of picking up the Learning Cocoa w/ Objective -C in addition. I'm wondering if the book is just a 2nd printing of the original book or is there a significant difference in content?

Thanks!

Josh

[Brass]

I wouldn't be suprised if it was just a new edition. The title pretty much describes what the first book was.

The original (Learning Cocoa), was a good book (it's what I used to learn Objective C and Cocoa), but it sure had some errors in it (mostly typos) that desperately required a new edition.

[JFischel]

The thing that makes me wonder is that the first thing they describe in the blurb is that it's updated for Jaguar. Are the APIs that much different?

Josh

[yeslekmc]

Originally posted by JFischel:
Does anyone have this book? I have the Learning Cocoa book, and I was thinking of picking up the Learning Cocoa w/ Objective -C in addition. I'm wondering if the book is just a 2nd printing of the original book or is there a significant difference in content?

I have both books. The 2nd addition arrived from Amazon a couple of days ago. These are two totally different books. The first book wasn't hardly worth the paper it was printed on, it was mostly just a thrown together collection of rag-tag tutorials from Apple's web site. You could tell that no one person was responsible for writing all of the material.

As for book II, Learning Cocoa w/ Objective C, this book is great! It contains programming examples than the first, and the book covers a whole slew of topics ommitted by the first version. Surprisingly, the book is thicker too, but only because it's on quality paper. The book itself contains fewer pages (by only a dozen or so) than the original. But the content is NOT the same as before. A little bit of it is the same, but for the most part one person took it upon themselves to make sure that all of the material was presented in a consistent manner.

NOTE: There is a consistent typo in the code throughout the book though that I'm sure was introduced by the printers and NOT the author. Code snippets like: NSString *someString = @"Dude!"; appear like this: NSString * someString = @"Dude!"; (note the space between the pointer and the variable name.)

Here's a run down of the chapters:[list=1][*]Introduction to Cocoa[*]Cocoa Development Tools[*]Object-Oriented Programming with Objective-C[*]The Cocoa Foundation Kit[*]Graphical User Interfaces[*]Windows, Views, and Controls[*]Custom Views[*]Event Handling[*]Models and Data Functionality[*]Multiple Document Architecture[*]Rich-Text Handling[*]Printing[*]Bundles and Resources[*]Localization[*]Defaults and Preferences[*]Accessory Windows[*]Finishing Touches[/list=1]
Compare it to the first book and you'll see what a difference it is.

Thanks!
---> Kelsey McClanahan

[Chuckit]

Originally posted by yeslekmc:
NOTE: There is a consistent typo in the code throughout the book though that I'm sure was introduced by the printers and NOT the author. Code snippets like: NSString *someString = @"Dude!"; appear like this: NSString * someString = @"Dude!"; (note the space between the pointer and the variable name.)

How is that a typo? Those two pieces of code are equivalent.

[yeslekmc]

Originally posted by Chuckit:

How is that a typo? Those two pieces of code are equivalent.

Wow! I didn't know that... I just tested it out and you are 100% correct.

After all these years I've always used pointers in C without a space between the * and the variable name. (We're talking since 1988). Is this just an Objective-C standard? I could've sworn that compilers used to mistake this for multiplication and would generate syntax errors. (In fact, at a glance it still LOOKS llike multiplication to me, I'll continue to use it without a space.)

Thanks for pointing this out...

[Rickster]

NSString* foo = @"foo";
NSString *foo = @"foo";
NSString * foo = @"foo";

These three are all equivalent. Common ObjC/Cocoa convention is to use the second one (as in Apple's framework headers), but any will work. I don't think gcc has had a problem mistaking the third for multiplication in a long long time. An unsigned long long time, even.

[LordJavac]

This is perfectly valid C/C++/Obj-C. I'm suprised that it was ever a problem. It's exactly the same as '-' which determined to be unary or binary by the context. It's often a programmer preference to use one of the methods (usually the type* variable and type *variable versions).

[Brass]

Of course there is one disadvantage to having the "*" next to the type, and that is in readability in some contexts.

For example,

NSString* foo, bar;
NSString *foo, *bar;

are two completely different things. Therefore, the "*" logically belongs with the variable name, NOT with the type name, although the syntax allows you to write it both ways (as well as with whitespace on both sides).