RE: Category or Protocol? (sidetrack)
RE: Category or Protocol? (sidetrack)
- Subject: RE: Category or Protocol? (sidetrack)
- From: Jeff Laing <email@hidden>
- Date: Wed, 20 Apr 2005 13:18:35 +1000
> (2) I find it easier to think of the interface as the union of the
> specifications. I need to chase back up the inheritance tree
> for all the methods anyway (in C++ or Obj-C), so little is gained by
> double-declaring methods (in child + parent).
My problem with this is where an object is to be used as a delegate.
There is no indication in the header, since there's no requirement to
inherit from a specific protocol (or worse, its already been inherited for
you right back up in NSObject.
My interfaces currently look like
@interface myclass {
...
}
// initialisers, accessors
...
// NSApplication delegate stuff
...
// NSXMLParser delegate stuff
...
@end
with those exact comments. This makes it very clear to me that myclass is
used as delegate in a number of places. I do the same in C++ for the same
reasons, though there you can *usually* use the superclass list for the same
thing.
I'll confess right now that I have spent days previously chasing a bug that
I just couldn't understand, where I couldn't work out why a particular
delegate method wasn't being called and it came down to me having put it
into *the wrong source file*, and thus the wrong class.
In my source files, I tend to have chunks sectioned off with:
////////////// NSApplication delegate stuff ////////////////////
comments so that I can locate things. Yes, I could use the various popup
widgets in XCode but so far they just haven't stuck in my unconscious. And,
of course, I need to remember the long-winded method names that correspond
to the various delegates.
Another thing I find very frustrating about Obj-C is this insistence on the
entire implementation being defined in the one compile-unit (ala Pascal).
Browsing 5000+ line source code, especially "samples from the net" can be
quite difficult.
The obvious fix to this is to use #include pulling multiple text files into
the one .m
(Of course, now you can tell how I did the "delegate method in the wrong
class" thing, can't you? ;-)
Has anyone else resorted to this sort of thing? Or am I the only person who
still finds that "more than seven functions per file fills up short-term
(neuronal) memory"? (ok, its more like thirty but seven sounds so much more
scientific)
> (3) When looking an an implementation file, it's very easy to
> tell which are overridden methods - they don't have a matching entry in
> the header file
Sorry, I don't see this one at all.
a. I have to look in two files, not one, to tell which entries in one
file don't have a corresponding entry in the other.
b. I thought it was legal to put "implementation-only" methods into the
.m file without having a corresponding declaration in the .h provided that
the definition of the method precedes its use.
Its possible that I think a) is a problem because I don't know about some
magical key combination in XCode that flips from definition<->declaration -
I think it used to be Clover-space in CodeWarrior but can't say for sure.
In any case, I like to type this stuff so I'll be able to read it quickly
and easily regardless of the IDE I'm working in.
If I'm wrong on b), I apologise but I'm pretty sure I've used this as an
"implementation-privacy" approach. Its one of those things that I always do
in C/C++ and used to even back in the Pascal daze.
> (4) While adding a redundant method declaration does not logically change
> the header file, it does change it syntactically and thus require
> recompilation of all associated implementation files.
Back in the bad old days, this used to bother me. But even an eMac is
plenty fast enough for my project needs, to recompile everything.
And I haven't come across any cases yet where I realistically needed to
#import the interface for a class into hundreds of source files anyway -
messages tend to be between little "cliques" of objects who need to know
about each others interfaces a lot and the "cliques" tend to talk via
methods that are coming from NSObject anyway.
Knowing when to use #import "myclass" and when to use @class myclass;
greatly helps factoring code into bite-sized compilable chunks, in my
experience.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden