Re: NSDictionary allocation
Re: NSDictionary allocation
- Subject: Re: NSDictionary allocation
- From: Ali Ozer <email@hidden>
- Date: Tue, 15 May 2007 09:08:07 -0700
With only a handful of exceptions (see NSObject, NSProxy,
NSFormatter, and a couple of others), none of the Foundation classes
are made to be subclassable. The reason is because classes like
NSArray, NSDictionary, NSSet, NSNumber, NSURL, etc. are actually
class clusters instead of concrete classes.
Actually, for the record, I would say the opposite; Foundation classes
such as NSString, NSDictionary, etc are meant to be subclassable,
provided you're willing to provide the storage implementation. As
you say, the class cluster approach means that the concrete classes
are not available for you to subclass. However, the abstract classes
have a clean design that allows them to be subclassed by overriding
just a few methods.
For instance, a functional NSString subclass can be created by
overriding length and characterAtIndex: (we also recommend
getCharacters:range: for performance). NSMutableString requires one
more method. NSArray subclass requires two methods; NSMutableArray
adds five more. By providing implementations for these primitive
methods, you get every other method in the class, including those
added by arbitrary categories.
This approach makes sense since we don't want to encourage subclassing
objects like NSString, NSArray in ways which changes their basic
identity (for instance, you don't want to subclass NSString to create
NSAttributedString, since that is fundamentally a new type). To just
extend their functionality based on their existing attributes,
categories are usually enough. This leaves alternate storage
implementation as the big reason for subclassing.
And of course the "alternate" storage can simply be an instance of
NSString or NSArray you point to from your subclass.
Ali
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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