Re: Mutable and immutable class cluster implementation / "method swizzling" question
Re: Mutable and immutable class cluster implementation / "method swizzling" question
- Subject: Re: Mutable and immutable class cluster implementation / "method swizzling" question
- From: John Engelhart <email@hidden>
- Date: Fri, 25 Mar 2011 02:02:58 -0400
On Fri, Mar 25, 2011 at 1:30 AM, Louis Gerbarg <email@hidden> wrote:
> The corner case you mention below ( [myMutableArrayInstance
> isKindOfClass:[NSMutableArray class]] ) is a nonissue for a somewhat
> surprising reason. All instances of NSArray are actually implemented via the
> concrete class NSCFArray, which is a subclass of NSMutableArray. Thus any
> instances of mutable or immutable arrays return YES to isKindOfClass for
> both NSArray and NSMutableArray. The only time that is not true is when
> people implement custom subclasses of NSArray. Thus no one can depend on
> that particular construct working unless they have implemented their own
> subclasses.
>
I've spent quite a bit a time plumbing the depths of the system, on this
issue and others. And even though I was vaguely aware (and had differently
observed it over the course of implementing my solution) that both NSArray
and NSMutableArray concrete, instantiated objects both share the class
"NSCFArray" at run time... that last little leap that NSCFArray ->
NSMutableArray -> NSArray quite never happened, for some reason.
Sometimes, a fresh pair of eyes... :) (thanks, btw)
> For that reason, you can probably completely ignore the issue. If you care
> about behaving like Apple's imps I would suggest that you should make your
> immutable class a subclass of NSMutableArray, and just have it's mutation
> methods throw exceptions. Implement your mutable array as a subclass of
> that. That will actually give you the same (somewhat counter intuitive)
> behavior as the builtin classes. Better yet, you could do exactly what they
> do, have a single implementation and control whether mutation works or
> throws by setting a bit.
>
Yep, a quick check shows that the immutable variant do indeed
-respondToSelector: for the mutating methods, but the immutable variants
throw a 'NSInternalInconsistencyException' with a '*** -[NSCFDictionary
setObject:forKey:]: mutating method sent to immutable object' reason.
> (Everything I said about arrays is equally applicable to dictionaries,
> sets, and strings)
>
This is obviously the "better" way when you need to implement both the
mutable and immutable versions of the systems class clusters.
I can't recall seeing this approach advocated in any of the official
documentation. On a zero order approximation, I can't find anything wrong
with it in terms of "acceptable and commonly accepted Cocoa programming
practices" from either an "Officially Documented" and "in practice"
perspective. Since this is code that is intended to be used by others (who
will likely use it on iOS), there is a very strong desire to do it
"correct", for some strong definition of correct.
_______________________________________________
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