Re: Comparing the Class
Re: Comparing the Class
- Subject: Re: Comparing the Class
- From: "Ken Ferry" <email@hidden>
- Date: Wed, 15 Oct 2008 19:41:02 -0700
On Wed, Oct 15, 2008 at 7:18 PM, Chris Idou <email@hidden> wrote:
>
> A category could be a nice OO solution here that avoids having the dreaded
> if else.
..as long as the method name is not too generic.
Early in Leopard, iChat and Mail both had some mysteriously broken behavior
with some AppKit code for interpreting an object that originally came from
user defaults. It looked something like this:
if ([default respondsToSelector:@selector(boolValue)])
return [default boolValue];
else if ([default isKindOfClass:[NSString class]]) {
return {determination if string looks like a @"YES" or a @"1" or
whatever goes here}
}
The problem was that Message.framework, which was loaded by both, had a
category that defined boolValue on NSString, and the definition of what
strings were considered true was a little bit different than the
determination in AppKit. So any app that loaded Message.framework (which is
a public framework) would interpret certain a global defaults differently
that any other app.
This particular issue won't come up again, because 10.5 introduced
-[NSString boolValue], and the AppKit code was rewritten anyway. :-) But
the point is, categories pollute the global space of methods. They're
great! But when adding methods to framework classes, use method names that
no one else would be interested in, by prefixing if nothing else.
-Ken
Cocoa Frameworks
>
>
> --- 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
>
_______________________________________________
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