Re: AppKit source available as reference?
Re: AppKit source available as reference?
- Subject: Re: AppKit source available as reference?
- From: Tom Waters <email@hidden>
- Date: Thu, 28 Jun 2001 11:54:23 -0700
I hate to chime in on a relatively non-dev topic, (especially since I
was the one who asked this question on omni-dev a few months back) but
here I go...
One of the many reasons that Java did as well as it did (say what you
will about the merits of the language) is that the source to all of the
classes was freely available. Not open source, not GPL, but at least
readable by developers. It was trivial to figure out how to extend the
JFC classes because you could read the source to the thing you were
extending, but more importantly, you could read the source to other
classes that would be calling into your object at runtime.
One of the great mysteries of Cocoa programming for me, and I believe
this is exacerbated by the widespread use of delegation, is WHAT methods
will be called WHEN on my classes. Because there is very little use of
formal protocols in AppKit, you can never really know if your class is
sufficiently implemented to behave as a complete delegate or
implementation for anything. You may have misspelled some method
signature, or left one or two out. The only way to know what is
expected of your class is to either read the source of another one that
you are most similar to, or read the source of those other classes that
depend on your class behaving in some way or another.
I can think of many examples of this, but in particular, NSCell is a
good one. If you implement a custom NSCell that you want to behave like
the built-in ones, how can you be sure you've covered all the bases,
without being able to see how (for example) NSTextCell, or NSBrowserCell
are implemented? Can you tell from the documentation what order
editWithFrame:inView:editor:delegate:event: is going to be called in
relation to selectWithFrame:inView:editor:delegate:event: ? Or for that
matter, do you have any guidance as to what your cell should DO to the
editor inside these methods? Certainly not from the documentation.
It seems to me that the documentation, and most of the example code
shipped with the dev tools, is geared towards the most basic uses of
these classes. "Instantiate one in IB, provide simple delegates which
extend NSObject" and that's it. If you need any serious custom
behavior, or a custom look, you are left having to guess how the main
classes work and interdepend.
It is clear that there is a long history behind why these classes behave
the way they do, and why they are designed the way they are. We can
guess that the flatness of the hierarchy and the promiscuity of the
classes (look at all the subclass specific kruft in NSView) is due to
the fact that when these were designed (in George Bush Sr.'s day) they
had to run on 68020's with 4Meg of ram. Reasonable tradeoffs were made,
but now that we are a decade in the future, it seems like the only map
to these decisions is the source.
I don't feel like I am alone in feeling that there's a bit of a brick
wall once you get past the simple stuff in AppKit. The easy stuff is
super easy, and once you understand ObjC and the reference counting
mechanism and a few of the method naming conventions, writing generic
code is fast and productive. But I've been programming on this platform
for 3 months, and while I feel proficient enough to *create* just about
any class I can think about, I still haven't been able to break into
many of the "black boxes" that are the AppKit classes.
Sorry for this turning into a rant, I could be wrong, but the fact that
I've posted a dozen or so AppKit questions to this list without a single
reply makes me think, either the rest of you are in the same boat, or
you all understand it perfectly well and don't want to reply to the
newbie questions. Occam's Razor.
Thanks for listening.
On 6/28/01 12:13 PM, "Karl Goiser" <email@hidden> wrote:
I used Smalltalk for a few years. You get the source to pretty well
everything and, generally, just fairly high-level documentation.
The source provided me with invaluable insights into how to program
in Smalltalk. With a source browser, I would scan through likely
classes, finding relevant methods and who called them and why. In
the calling methods, I would find the style of usage of the methods -
examples.