A category could be a nice OO solution here that avoids having the dreaded if else.
--- On Wed, 10/15/08, Ken Ferry <[EMAIL PROTECTED]> wrote: > From: Ken Ferry <[EMAIL PROTECTED]> > Subject: Re: Comparing the Class > To: "Graham Cox" <[EMAIL PROTECTED]> > Cc: "cocoa-dev Dev" <Cocoa-dev@lists.apple.com> > Date: Wednesday, October 15, 2008, 6:59 PM > > …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 PROTECTED]> 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 (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/kenferry%40gmail.com > > > > This email sent to [EMAIL PROTECTED] > > > _______________________________________________ > > 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/idou747%40yahoo.com > > This email sent to [EMAIL PROTECTED] _______________________________________________ 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 [EMAIL PROTECTED]