> …because you can't force an existing class to conform to a protocol
without subclassing.
A category can add a protocol adoption, actually.
-Ken
On Wed, Oct 15, 2008 at 6:37 PM, Graham Cox <email@hidden> wrote:
>
> On 16 Oct 2008, at 12:20 am, Ruotger Skupin wrote:
>
> Hi,
>>
>> when comparing the class of two objects I usually do [obj1
>> isKindOfClass:[obj2 class]]. But if I say have the Class as an input value
>> to a method:
>>
>> - (void) bla:(Class) inClass
>> {
>> if (/* inClass is an NSString */)
>> {
>> // do stuff
>> }
>> else if (/* inClass is an NSNumber */)
>> {
>> // do other stuff
>> }
>> }
>>
>> Is it save to compare like this:
>>
>> inClass == [NSString class]
>>
>> or do I have to e.g.:
>>
>> [[NSNumber numberWithInt:0] isKindOfClass:inClass]
>>
>> Roddi
>>
>
>
> As well as what others have said, consider not testing the class at all but
> instead testing for a response to a particular message of interest
> (so-called "duck typing" - see http://en.wikipedia.org/wiki/Duck_typing).
> That can be a lot more flexible. Another option is to declare a formal
> protocol that is common to the possible classes of interest, though in the
> example that wouldn't work because you can't force an existing class to
> conform to a protocol without subclassing.
>
> --Graham
>
> _______________________________________________
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
>
> This email sent to email@hidden
>
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
This email sent to email@hidden
