Re: Docs, questions and stuff
Re: Docs, questions and stuff
- Subject: Re: Docs, questions and stuff
- From: Chris Gehlker <email@hidden>
- Date: Fri, 24 Aug 2001 21:07:24 -0700
On 8/24/01 3:53 PM, "Jonathan Hendry" <email@hidden> wrote:
>
>
Um, no, they don't. Interfaces and protocols are rather different
>
from C++-style MI.
Protocols aren't how one does MI in ObjC. Think forwarding.
>
You can't have a class (ObjC or Java) inherit from two superclasses.
You really can't in Java which leads to a lot of messing with inner classes
and can get quite ugly. Sun, however, says this is a form of MI and I
wouldn't disagree. I only disagree that it's superior to C++ MI.
Forwarding is a form of MI and a very nice one. More elegant than the C++
method. But it can be more elegant because of dynamic linking. And it is
very similar to the way most C++ compilers do MI. The difference is only
that between looking up an address dynamically versus doing it at compile
time and sticking it in a vector.
>
>
Yes. The book is about Cocoa. It doesn't teach that "OO is
>
___only___ for accessing the Cocoa frameworks".
>
>
Unless you'd like to point to the page number where the book
>
says that OO is not to be used for anything but accessing
>
the Cocoa frameworks?
Take a look at the presentation starting at page 287. Look particularly at
what they say is "left as an exercise". Imagine a poor student actually
doing this exercise. Isn't this exactly teaching by example that "OO is not
to be used for anything but accessing the Cocoa frameworks?
Here is an exercise for you. Come up with a OO way to do this that meets the
following criteria.
1) It's much shorter.
2) It's much clearer.
3) It's trivial to extend to n panels.
Hint - Polymorphism.
>
No, you missed. Learning Cocoa is about Learning Cocoa,
>
thus, OO is presented in the context of using Cocoa, which
>
is the entire reason for the existence of the book.
>
>
Why would you expect to find the book spending copious time
>
covering generic OO topics? It's already trying to cover
>
too much in too little space.
So why take up precious space with examples that look like there are no such
things as encapsulation or polymorphism. Let me make this very plain. The
problem with the book is not that it is incomplete. The problem is that it
is wrong. If they would take the poor examples out, they would have room for
some good ones.
>
>
The Cocoa frameworks are a nice OO design. They certainly get mentioned a
>
lot in Design Patterns. Learning how to use them is a good start at
>
learning-by-example.
Indeed they are. And in the case above, NSTabView solves a very similar
problem in an elegant way. The good C++ books also solve this type of
problem in a way very similar to NSTabView. There are lots of examples of
the right way to do this. So why do the authors of "Learning Cocoa" ignore
all these good examples and write spaghetti code? Why is the very first
serious challenge to the student, "Please expand our spaghetti code"?
>
Actually, my attitude is from seeing the other students agonizing over
>
how to do something, and thinking "this would be so much easier
>
in Objective C".
And it would be. If there were a good ObjC book that was in print, I would
have recommended it. I made that very clear.
But right now that choice is a luxury no one has. So I think that the best
we can do is find a book that gets the principles right in a related
language.
--
When I was a boy I was told that anybody could become President. Now I'm
beginning to believe it. -Clarence Darrow, lawyer and author (1857-1938)