Re: Comparing the Class
Re: Comparing the Class
- Subject: Re: Comparing the Class
- From: Chris Idou <email@hidden>
- Date: Wed, 15 Oct 2008 19:18:07 -0700 (PDT)
A category could be a nice OO solution here that avoids having the dreaded if else.
--- On Wed, 10/15/08, Ken Ferry <email@hidden> wrote:
> From: Ken Ferry <email@hidden>
> Subject: Re: Comparing the Class
> To: "Graham Cox" <email@hidden>
> Cc: "cocoa-dev Dev" <email@hidden>
> 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@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:
> >
> >
> > 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:
>
> 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:
This email sent to email@hidden