Re: Docs, questions and stuff
Re: Docs, questions and stuff
- Subject: Re: Docs, questions and stuff
- From: Jonathan Hendry <email@hidden>
- Date: Sat, 25 Aug 2001 00:13:34 -0500
On Friday, August 24, 2001, at 11:07 , Chris Gehlker wrote:
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.
That's a form of delegation, not MI. Rather different. Multiple
Inheritance is, by definition, an issue of type. Delegation
doesn't imply anything about type.
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.
What, you mean the switch statements? How do you propose to
use Polymorphism? The switches aren't comparing against
the type of something, like you'd find in most OO book
explanations of polymorphism. (frex, switch statements
discriminating between circles, squares, and triangles.)
The switches are on the values selected by the user for things
like 'seconds until notification'. That wouldn't make a good
basis for polymorphism. What are you going to have, a
15MinutesToDoItem, a 60MinutesToDoItem, etc? Or maybe a
15MinutesCell, 60MinutesCell. (Wouldn't work anway. IIRC,
NSMatrix can't mix cell classes.)
They _could_ have put things like the switch(notifySecs) on
page 288 into subclasses of SelectionNotifyMatrix, so
they could have just said [infoNotifySwitchMatrix setNotifySecs:...].
But that would have just moved the switch into the Matrix class.
Better, but not perfect. I'm not sure you can get rid of
the switches.
Anyway, using polymorphism would have required more space
to cover the additional classes. I'm sure the book could
have been perfect in all ways if they'd wanted a 3,000 page
book.
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.
No, it is not wrong.
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, it's a pretty common idiom from the NeXT days. In
situations where you don't have the room for a a tabview
(which get wide quickly as you get more tabs), you
use something like this.
By the way, a TabView really wouldn't help much, IMHO. That
just automates the view swapping, which is working before
pg 287.
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.
How is Apple's Objective-C book (not Learning Cocoa) deficient?
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.
For the OO principles, that would be Java, which at least approaches
the dynamic features of ObjC. C++ is too static.