RE: Category or Protocol? (sidetrack)
RE: Category or Protocol? (sidetrack)
- Subject: RE: Category or Protocol? (sidetrack)
- From: Jeff Laing <email@hidden>
- Date: Tue, 19 Apr 2005 14:57:02 +1000
> Since these methods are available to all NSObjects (and, by
> inheritance, whatever object you want to be the delegate), all
> you need to do is set your object to be the parser object's
> delegate and then implement (override) the methods specified
> by the category. You don't need to declare anything special,
> because the category declaration has already done that for you.
Since I'm carrying around all this C++ baggage in my head, I've often
wondered as to "style" here, and would be interested in what the Objective-C
gurus think of this.
(Please note, this is not an invitation to start a C++ vs Obj-C discussion,
its a question as to best practices in Obj-C, specifically on method
overloading)
In C++, its mandatory to re-declare the methods of your superclass that you
override, and in practice, I've found that that makes for less bugs of one
sort, and more of another.
Objective-C doesn't have this requirement and I'm curious as to whether any
experts want to comment on whether its "good practice" to omit the
overridden method declarations.
On the plus side, its a lot easier to look at a header file and decide what
sorts of things the class must do. I *think* it also enforces that you
actually implement the overridden method at compile time, but I'm away from
my Mac so I can't confirm that.
On the minus side, well, its more typing that is presumably prone to subtle
typos, especially if you're like me and populate the .h, then cut/paste your
method prototypes across to the .m file and then fill it out. If you
copy/paste from the online documentation to set up your .h prototypes you're
fine, but if you then edit them into shape (to match local coding
conventions) and manage to lose a character in a method name, it can take
forever to find.
_______________________________________________
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