Re: Category or Protocol? (sidetrack)
Re: Category or Protocol? (sidetrack)
- Subject: Re: Category or Protocol? (sidetrack)
- From: Ondra Cada <email@hidden>
- Date: Wed, 20 Apr 2005 14:39:35 +0200
Jeff,
On 20.4.2005, at 5:18, Jeff Laing wrote:
(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.
That's the right way of doing thins.
One object often serves as a delegate for a lot of others, therefore
there can't be a fixed delegate class. And it is *extremely* common you
implement only a small number of all the delegate methods: that's why
there can't be a formal delegate protocol.
My interfaces currently look like
@interface myclass {
...
}
// initialisers, accessors
...
// NSApplication delegate stuff
...
// NSXMLParser delegate stuff
...
@end
...
In my source files, I tend to have chunks sectioned off with:
////////////// NSApplication delegate stuff ////////////////////
comments so that I can locate things.
Divide the code into categories if you want to:
@interface YourClass...
@end
@interface YourClass (NSApplicationDelegateStuff)
@end
@interface YourClass (NSXMLParserDelegateStuff)
@end
Note the interfaces may, but need not, to be in separate header files:
whatever you prefer.
With implementations you would much probably *want to* place them into
separate .m files, but again, you need not.
...And,
of course, I need to remember the long-winded method names that
correspond
to the various delegates.
Long-winded method names are remembered *MUCH* more easily than
abbreviations. It is easy to remember
applicaiton:didFinishLaunching:
On the other hand, had it be something like
app:didFinishLaunch: or app:FinisnedLaunch: or a:dfl:, well, *that*
would be a mess :)
Another thing I find very frustrating about Obj-C is this insistence
on the
entire implementation being defined in the one compile-unit
It does not and never did insist on something such. Again, check
categories :)
Browsing 5000+ line source code, especially "samples from the net" can
be
quite difficult.
Definitely. A decent implementation file should always fit the screen,
to be seen complete without scrolling :))
The obvious fix to this is to use #include pulling multiple text files
into
the one .m
Jeez, no! That's ugly. The very obvious -- well, not "fix", since it is
how it was designed and clean -- way are the categories.
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.
There is much weaker correspondence betwixt what you see in @interface
and in @implementation than you are used to from the C++ rot.
In ObjC, @interface declares *messages*. @implementation defines
*methods*. They do not have that much in common!
Any message can be sent to any object. The one and only common point
happens here: if the object happens to have a method of the same name
as is the message name, the method is called.
It does not need to. The message can be re-directed to a different
object without even checking its contents. Or it can be interpreted
dynamically: it is easy to implement a object in Objective C, which
would return a zero for any message which begins with "a", and a number
of characters in the message name for any other message.
The compiler does make some compile-time checking to prevent obvious
typos and to -- far as it is possible -- convert properly plain C types
(like, ints to floats), but that's all.
There's more, but I'm a bit in hurry :)
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
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