On Fri, Mar 25, 2011 at 1:30 AM, Louis Gerbarg <lgerb...@gmail.com> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
