• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: object type testing
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: object type testing


  • Subject: Re: object type testing
  • From: Greg Titus <email@hidden>
  • Date: Sun, 7 May 2006 11:35:37 -0700


On May 7, 2006, at 11:22 AM, Uli Kusterer wrote:


Am 07.05.2006 um 17:41 schrieb Ben Dougall:
regarding finding out if an object instance is a particular type of class or not

Just to play the party pooper here: Keep in mind that, *in general* it's a sign of a mistake in your design if you need to check for a particular class. Especially in Cocoa, it is perfectly fine that an object may not be of a particular class, but rather of a class that implements the same methods or a subclass of a particular class. Even more importantly: NSString and several other fundamental classes of Foundation are actually class clusters and the class itself is an abstract base class. So, e.g. checking whether an object is of class NSString will always return false, because you only get objects of NSMutableString, NSCFString or whatever...


So, if you can, use conformsToProtocol, respondsToSelector or similar methods to check for the actual feature you need, and not for a particular class name.

Another gotcha to look out for in specific class checking is if the class ends up being used by Cocoa Bindings at all, the bindings observing goo will end up making a subclass of your class which is what all your actual objects will end up being. I.e. all your MyClass objects actually end up becoming KVObserving_MyClass objects instead. Similarly, fault objects or forwarding proxy objects may implement - isMemberOfClass: or -isKindOfClass: to pass along the call to the 'real' object involved since they are acting as if they are some other class.


Comparing specific class pointers or class names will break in all of these sorts of situations where other code is playing tricks with the runtime. Since things like key-value-observing are most definitely not local to your own code, and you can't guarantee that Apple won't change implementations of Cocoa features to play more of these sorts of tricks in the future, be VERY careful about specific class checks.

Hope this helps,
	- Greg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: object type testing
      • From: Ben Dougall <email@hidden>
References: 
 >object type testing (From: Ben Dougall <email@hidden>)
 >Re: object type testing (From: Uli Kusterer <email@hidden>)

  • Prev by Date: Re: object type testing
  • Next by Date: Re: object type testing
  • Previous by thread: Re: object type testing
  • Next by thread: Re: object type testing
  • Index(es):
    • Date
    • Thread