Re: How to create to-many accessor methods at runtime
Re: How to create to-many accessor methods at runtime
- Subject: Re: How to create to-many accessor methods at runtime
- From: Steve Weller <email@hidden>
- Date: Sun, 06 Jul 2008 21:21:18 -0700
On Jul 6, 2008, at 5:02 PM, Ben Trumbull wrote:
First, have you considered the low tech approach of using a gcc
variadic macro (#define) ? <http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
> You can generate a lot of template code this way. With one line
of code per key you can generate all the accessors you need.
I had not considered this. However I do want to set up the methods at
run time since the action of the methods depends on how a number of
other objects are set up and attached.
A second option would be to override -mutableArrayValueForKey: to
return a proxy object that knows both the source object and the key
and fulfills the mutable KVC contract. Basically, this is creating
a subclass of NSMutableArray that knows how to properly handle your
source object, it's key.
My class only presents a set of immutable to-many accessors. But now I
am wondering -- if I do that my values may get optimized away by
another object that thinks the values never change. I should probably
add the mutable accessors too, even if they do nothing.
On 10.5, you have an additional hook that is invoked before
forwarding:
+ (BOOL)resolveInstanceMethod:(SEL)sel;
This is much more efficient than forwarding, and the result is
cached, so method resolution is only invoked once per selector. It
does require some nasty "parsing" of the selector, and use of the
raw objective-c runtime functions to register the new method on the
class.
That's an interesting option. My selectors are fixed, so that would
not be too bad.
-forwardInvocation: is the least efficient choice, although it can
be handy under some circumstances where flexibility is the most
important design issue.
I'm sticking with that for now. Another responder set me straight
about -respondToSelector being only for he convenience of other
methods. I can say YES as long as I actually implement the dynamic
methods somehow. NSInvocation is a good container for all the
information I need, so I also use it to call the method. I set up one
NSInvocation per method and select the correct one based on the
selector I am passed after dropping the arguments in as needed, then
transfer the return result back.
- Ben
Steve Weller email@hidden
Technical Writing, Editing, Developer Guides, and a little Cocoa
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden