Re: cocoa-dev digest, Vol 2 #2848 - 10 msgs
Re: cocoa-dev digest, Vol 2 #2848 - 10 msgs
- Subject: Re: cocoa-dev digest, Vol 2 #2848 - 10 msgs
- From: Brian Donofrio <email@hidden>
- Date: Tue, 26 Aug 2003 12:06:56 -0700
On Monday, August 25, 2003, at 10:00 PM,
email@hidden wrote:
Well we have about 8 books on Cocoa. We need more, especially with the
new Xcode.
Instead of tearing apart this book why don't you write one. I would
love to see a Cocoa book
written by somebody like the Deitel family or Stephen Prata. That
would be a 1000 + page
book with 100's of examples, multiple choice questions, exercises and
answers along
with a solid teachers manual. Why don't we get this quality?
Publishers want to make money
and Cocoa is a obscure language on a platform thats future is
questionable. I think any of the
8 books on my list could have been the "Master Work" but it comes down
to $. You need a
good size team, a lot of people to come up with questions and answers,
debuggers, and time
to hone a text book that will last for decades. With updates and
versions. I almost think it would be Apples
interest to subsidize say the Deitel group to create a book. They have
a deal with O'Reilly and that probably
won't happen, O'Reilly books are well...the best we got.. and they
have cute animals on the cover.
How many people have studied Stephen Prata's C++ Primer Plus or Deitel
& Deitel's C++ How to
program? These are what I consider a computer book at it's best most
evolved form. The sooner
we get one of this quality the faster Cocoa can grow.
Times are tough on the Cocoa book front, Take it easy on Joe Zobkiw.
He has been with the Mac since
the beginning and unless you can do better, positive encouragement
rather than whining about the word
Advanced isn't going to help matters.
Brian Donofrio
Message: 4
Date: Tue, 26 Aug 2003 01:33:17 +0200
Subject: Re: logical (! object) vs (object != nil)
Cc: cocoa-dev list <email@hidden>
To: Anders Totland <email@hidden>
From: Marco Scheurer <email@hidden>
On Tuesday, August 26, 2003, at 12:46 AM, Alastair J.Houghton wrote:
On Monday, August 25, 2003, at 07:39 pm, Anders Totland wrote:
I have a (C noob) question. Are the two statements (! object) and
(object != nil) the same statement, with identical meaning?
They are expressions and not statements, but yes, they are identical
(since nil is zero).
I know it's a typo but as written, they are the opposite of each other.
In practice, (!object) and (object == nil) are the same, and which one
you use is a matter of style and preferences.
See "Is the abbreviated pointer comparison 'if(p)' to test for non-null
pointers valid? What if the internal representation for null pointers
is nonzero?" at
http://www.eskimo.com/~scs/C-faq/q5.3.html
Marco Scheurer
Sen:te, Lausanne, Switzerland http://www.sente.ch
--__--__--
Message: 5
Date: Tue, 26 Aug 2003 01:32:11 +0200
Subject: Re: Help me, which book I should buy to learn Cocoa??
Cc: email@hidden
To: Don Arbow <email@hidden>
From: Georg Tuparev <email@hidden>
On Tuesday, August 26, 2003, at 12:15 AM, Don Arbow wrote:
Anyone who is familiar with Zobkiw's first book, "Fragment of Your
Imagination", would be quite at home with his latest.
OS 9 and OS X are different beasts. Many people who loved OS 9 do not
feel home surrounded by pumas, jaguars, panthers and other pussycats -
and there's nothing wrong with this. It is called progress, and as it
happens some just miss the train, and stay home, and talk about the
good old days. The important point is that OS9's home is not in the
same town as OSX home, and there is no point of comparing them!
Just as pre X versions of Mac OS required advanced knowledge in order
to accomplish non-standard things (remember code fragments, MDEFs and
WDEFs?), so too do certain things in Mac OS X require a different type
of book.
Different yes, wrong - no. I was trying to avoid strong words in my
first posting, but now my adrenaline start really boiling. To give
examples like
[colorSettings setTheColorOfMySistersEyes:@"blue"];
[colorSettings setTheColorOfMyBrothersEyes:@"green"];
and few pages to go, is neither educative nor represent correctly basic
concepts behind MacOS X (Cocoa). And Mr. Zobkiw obviously does not
understand things like polymorphism, metadata etc... If I show this
book to an average MFC coder, she will start laughing and I will be
asked how it is possible to use such archaic coding practices. This
certainly does not reflect the truth about Cocoa!
Mac OS X Advanced Development Techniques is certainly advanced, maybe
not in the Cocoa sense
If you are trying to say that many OS9 advanced techniques could be
done with just few clicks in IB and loose the right to be called
advanced, I am with you. But then why one should try to make the life
difficult just for the trill of doing "advanced" things?
(it won't teach you how to create a multi-window behemoth application
like InDesign). Not everything in Mac OS X development can be done in
an object oriented manner,
Really? Examples please!
this book shows how to accomplish things such as writing a preference
pane to work in the System Preferences app,
and what is advanced about this one when even the PB has Preferences
template, and any beginner's tutorial tells you about how to write it?
wrapping a command line app with a GUI, how to use Cocoa threads
Ah! Why just not read NSTread class documentation? It is not a rocket
science, believe me!
or write a Carbon plugin.
yeah. Carbon dating was one of my worst experiments during my physics
classes.... I almost missed the test. It happens again with me as a
programmer ... only this time I do not feel disappointed about it ;-)
I certainly wouldn't recommend this book for Cocoa newbies, but the
word "Advanced" in the title should serve to warn newbies that this
book is not for them.
Unfortunately the word "Advanced" might attract some non-newbies.
-- georg --
"More Trees, less Bushes!"
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.