views:

98

answers:

3

ok.. think of objectA.. objectA has optional properties defined in its protocol. the delegate may or may not implement these, but if you do decide to implement them, you must provide a valid return.

now what if i have objectA.delegate set to objectB but object be needs to implement them all at compile time, and at runtime will decide which ones it may or may not support. The problem in implementing them all as stubs means that the objectA will simply use 'respondsToSelector' to see if the delegate is trying to use optional properties, and if so it will assume they are valid and use them.

Since objectB(delegate) has to decide conditionally which ones to implement, the only solution i can see is to use 'class_addMethod'.

I was hoping there could be a more elegant and possibly more optimal solution, but not sure as what it may be.

A: 

It sounds like you should probably read this

Azeem.Butt
the problem is i dont have access to that class. closed source sdk.
drunknbass
you're already modifying closed source code. how is class_addMethod not elegant or optimal enough?
nall
Then you can either swizzle or come up with a new designhttp://www.cocoadev.com/index.pl?MethodSwizzling
Azeem.Butt
A: 

Yeah, use NSObject's + (BOOL)resolveInstanceMethod:(SEL)aSEL in combination with class_AddMethod and hook up the implementation you want based on whatever criteria you want. Not sure if this is what you are looking for or not. Hope it helps.

bstahlhood
+1  A: 

Anytime you think you need to use class_addMethod() to implement something, you are almost always doing it wrong.

From what you describe-- which is rather vague-- an easy solution would be to create something that can both act as the delegate and can conditionally forward the methods, as needed.

Now, you say that if the delegate does implement a method it must return a valid value. If that is the case, class_addMethod() isn't really going to help. Most classes that implement delegates will check once if the delegate implements the method and then will assume it does forever unless the delegate changes. You could get into the business of switching delegates often, but down that path lies madness.

A better answer might be to ask a question; what are you trying to do?

bbum
I agree that modifying the class to implement the delegates I choose is not elegant. This class is single allocation, lives the life of the app so modifying the class is safe. Not all delegates accept a nil value or expose what they would ghandle as a default. Basically its a killum all and ask questions later approach. I assume responsibility to respond to all with user generated values, but need a way to safely pick and choose at runtime.I'd say so far addmethod is the only approach that would achieve exactly what I'm wanting to do.
drunknbass