Re: Category or Protocol? (sidetrack)

FROM : Ondra Cada
DATE : Wed Apr 20 14:39:35 2005

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_removed>              http://www.ocs.cz
private        <email_removed>            http://www.ocs.cz/oc