Re: Category or Protocol? (sidetrack)
Re: Category or Protocol? (sidetrack)
- Subject: Re: Category or Protocol? (sidetrack)
- From: mmalcolm crawford <email@hidden>
- Date: Wed, 20 Apr 2005 23:04:42 -0700
On Apr 20, 2005, at 9:12 PM, Jeff Laing wrote:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
ObjectiveC/Langua
geOverview/chapter_3_section_7.html>
Eh, I'm just making excuses, I should have read it all rather than
skimming
headings. Then again, who ever read Stroustrop from cover to
cover? Or
K&R?
In general it is preferred that developers read relevant material
before posting to the list. The reference above (and the accompanying
articles) addresses several of the issues raised in this thread.
If I have myclass which is going to act as a delegate to some other
object,
do the Obj-C gurus here suggest that its good/bad/indifferent style to
compartmentalise the corresponding delegate methods into a category?
Per the reference above, it's a perfectly reasonable thing to do.
Are there sneaky runtime characteristics that I'm going to invoke
that I, as
novice, can't see? I dunno, I might preclude people from doing isa
swizzling
on my classes, something like that? No idea why that would happen,
but
thats why I'm asking experts!
"The methods in the category become part of the class type (within
the scope of your program) and are inherited by all the class’s
subclasses. There is no difference at runtime between the original
methods and the added methods."
I can see where it wouldnt be too difficult to write a Q&D yacc
grammar that
I fed "myclass.h" into and it pumped out a "myclass-accessors.h"
file that
contained all the standard accessor methods in a category called
myclass(MyAccessors) ?
In general you should ensure that the style of accessor you use is
appropriate to the property (see for example <http://www.stepwise.com/
Articles/Technical/2002-06-11.01.html/>), for this reason alone I
would therefore personally not recommend wholesale use of a pre-
processor in this manner...
(I believe that Accessorizer does something like this, but I'm of the
understanding that its GUI based, not designed to be wired into a
makefile/xcode build. Or perhaps it is?)
... moreover Accessorizer makes generating accessor methods
sufficiently easy that it's difficult to see a benefit in
complicating the build process.
Moreover, (a) You would probably have to ensure that accessors were
only generated for those properties that needed them;
(b) You would have to ensure consumers of the class imported myclass-
accessors.h (to follow standard naming conventions this should be
MyClass-Accessors.h);
(c) You would presumably not see the header during normal development
-- the header typically provides useful information about the class's
public interface...
But would it be "a bad thing(tm)" to push all my accessor methods
out into a
category? And if so, why?
Again per the reference above, it would be perfectly reasonable.
mmalc
_______________________________________________
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