Re: forwardInvocation: and keeping compiler happy
Re: forwardInvocation: and keeping compiler happy
- Subject: Re: forwardInvocation: and keeping compiler happy
- From: Gerd Knops <email@hidden>
- Date: Fri, 12 Jan 2007 13:47:59 -0600
On Jan 12, 2007, at 1:08 PM, j o a r wrote:
On Jan 12, 2007, at 7:42 PM, Gerd Knops wrote:
The question is how do I keep the compiler and myself happy. I'd
like the compiler to know about the methods of ClassA in the
context of ClassB, so it can perform all it's type checking. I can
do that by declaring everything ClassA implements as a protocol
and have ClassB tagged as implementing that protocol. Now the
compiler compiles fine and also performs all the type checking.
But of course it warns that ClassB does not actually implement the
ClassA methods.
Is there a way to get around this, preferably without globally
disabling the otherwise useful warning "method definition for 'x'
not found"?
How about making ClassB a class cluster, where ClassB itself
implements stubs of the methods but is never used. Instead, the
object instances you return from ClassB is really of ClassC, and
ClassC implements forwarding, but doesn't conform to the protocol.
That might work, though at that point I am getting close to just
implementing the whole -method{otherObject method} shebang and avoid
all the issues. Maybe that's what I'll do in the end.
Another alternative is to not have ClassB conform to the protocol,
and instead make sure to cast all instances of ClassB to (id <
ProtocolA >) wherever they're used / acquired. To still be able to
use the "regular" methods from ClassB you could create a ProtocolB
with these methods, conform to it in ClassB, and then include it in
the cast: "id < ProtocolA, ProtocolB >).
Requires to much special treatment in the rest of the code, something
I tried to avoid.
Thanks!
Gerd
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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