RE: Category or Protocol? (sidetrack)
RE: Category or Protocol? (sidetrack)
- Subject: RE: Category or Protocol? (sidetrack)
- From: Jeff Laing <email@hidden>
- Date: Thu, 21 Apr 2005 12:15:47 +1000
> From: Ondra Cada [mailto:email@hidden]
> Divide the code into categories if you want to:
>
> @interface YourClass...
> @end
>
> @interface YourClass (NSApplicationDelegateStuff)
> @end
>
> @interface YourClass (NSXMLParserDelegateStuff)
> @end
Ok, this is something that really hadn't occurred to me. I've been operating
under the assumption that categories are something that you do to "someone
elses classes".
I guess my only hesistation here would be that I need corresponding member
variables in the base class definition to support the category
implementations, dont I? Then again, thats probably not a major issue.
> With implementations you would much probably *want to* place them into
> separate .m files, but again, you need not.
Actually, it seems to me that I'd be replacing
:
//////////////////// Application Delegate stuff ///////////////////
:
with
:
@end
@implementation myclass(ApplicationDelegateStuff)
:
which is going to be just as easy to find with a text editor, and
syntax-checked. I'm liking this idea more and more. I can still push it
out to an external file if the line count gets too high.
I'm interested in peoples opinions on what to name those external files.
I've seen lots of samples that use the Class+Category.m naming convention
but I'm hesistant to adopt a scheme that includes regexp() wildcards. Are
there any opinions on whether this way is safe?
(For example, I've had scenarios in the past where someone coded a perl
script "sub-optimally" and one construct they used accidentally treated a
filename as a regular expression. The "." characters still managed to
match, but "*", "?" and "+" made "interesting" matches)
> > ...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.
The issue was not trying to remember the method name, it was trying to
remember that something:(id)said:(id)on:(NSDate*) is the App delegate, not
the XMLParser delegate. And thats really a matter of the size of the class
library, not the language itself.
> > 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.
Agreed. Remember, this was my response to the assertion that you can tell
that a method is being overridden from a superclass, rather than being
defined for this class. That is only true if you don't use this "I'll give
you a prototype only if I need to expose this method" approach. Again, the
focus being on what is "best practice" and why...
_______________________________________________
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