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.
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. (Everything I said about arrays is equally applicable to dictionaries, sets, and strings) Louis On Mar 25, 2011, at 12:49 AM, John Engelhart <john.engelh...@gmail.com> wrote: > I've considered the "assume everyone and everything practices proper duck > typing" and just make @interface MYMutableArray : MYArray. There is one > corner case that I can think of where this breaks: > [myMutableArrayInstance isKindOfClass:[NSMutableArray class]]. Granted, > doing this is frowned on as "not proper Objective-C programming", but none > the less, I'm sure some people do it. I'm also not entirely sure how this > might interact with serialization, either NSCoder or property lists. > Currently, my spot checks of NSCoder behavior causes the instances to be > serialized as NSArray or NSMutableArray, which is just fine and what I want > since the sole reason that I'm creating these custom classes is for bulk > creation of collection objects very, very quickly. > > Can anyone think of corner cases in which these would not behave > "identically" to their respective concrete Cocoa versions? KVO / KVC? > Anything "weird" but still considered legitimate? The CoreFoundation > CFArray... / CFDictionary calls seem to work as expected (but I can't say > I've done a comprehensive test of everything). Fast enumeration and block > based enumeration works, though come to think of it I haven't tried the > "parallel" option. Distributed Objects... CoreData? I'd like to provide > "maximally compatible" if at all possible, and if not, then clearly document > the limitations / caveats. _______________________________________________ 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
