I always take the protocol route. You can implement other methods and do a
single cast to NSObject <nameOfProtocol>* (or id<nameOfProtocol> if you don't
need the NSObject methods) and then just pass around that. All you have to
check for in instantiation is that it passes implementsProtocol: and then
you're set. After that, not only do you typically have the ability to forgo
these warnings (they won't appear) but so long as you import the protocol
header, XCode will implement code completion for the protocol, which is nice.
I use protocols for internal classes for pull-up refactoring, too. After
creating and requiring the protocol in the object, if you change the
controllers, all you have to do is change the method name in the protocol.
XCode will throw warnings in all the places that the method should -but isn't-
implemented.
Dave
On Nov 26, 2010, at 10:27 AM, Mike Abdullah wrote:
> You have many options, in rough order of cleanness:
>
> A) Declare a protocol that your objects conform to. Make -setOrdinal:
> @optional
>
> B) Do [object performSelector:@selector(setOrdinal:) withObject:value] or use
> -setValue:forKey:
>
> C) Typecast the object to a class that is known to implement -setOrdinal:
>
> On 26 Nov 2010, at 17:47, Mikkel Eide Eriksen wrote:
>
>> I should have mentioned that it is declared, but obj can be one of many
>> classes only some of which have setOrdinal:
>>
>> On Nov 26, 2010, at 6:46 PM, banane wrote:
>>
>>> declare the method in your header file. "-(void)setOrdinal;"
>>>
>>> On Fri, Nov 26, 2010 at 9:08 AM, Mikkel Eide Eriksen
>>> <mikkel.erik...@gmail.com> wrote:
>>> Hi all,
>>>
>>> I have the following bit in my code:
>>>
>>> if ([obj respondsToSelector:@selector(setOrdinal:)]) {
>>> [obj setOrdinal:value];
>>> }
>>>
>>> XCode gives a warning that obj may not respond to setOrdinal: which won't
>>> be a problem unless something is really screwy. But how do I get rid of the
>>> warning? Or do I just live with it?
>>>
>>> Regards,
>>> Mikkel
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>
>>> 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:
>>> http://lists.apple.com/mailman/options/cocoa-dev/banane%40gmail.com
>>>
>>> This email sent to ban...@gmail.com
>>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> 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:
>> http://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net
>>
>> This email sent to cocoa...@mikeabdullah.net
>
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/zwerdlds%40gmail.com
>
> This email sent to zwerd...@gmail.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
