On Mar 24, 2011, at 10:49 PM, John Engelhart wrote: > I'm curious if anyone sees any problems with this approach... Again, I > haven't found anything on the web that covers this exactly, so there's no > prior experience to draw on / best practices. This is the first time I've > had to do both mutable and immutable classes of a collection class cluster. > I didn't even anticipate that there was a problem until I literally wrote > "@interface MYMutableArray : NSMutableArray .... ergh, but how exactly do I > inherit the MYArray methods I already wrote... ? hmmmm"
I would suggest doing: @interface MYMutableArray : NSMutableArray and @interface MYArray : NSArray then for the 'shared code', instead of putting it in MYArray.m and copying it in MYMutableArray.m, put it into a shared code file. Most times I've seen it done, developers use a '.i' extension. Then you can just include the '.i' file in both MyArray.m and MYMutableArray.m Pros: -don't need to worry about not updating common code -inheritance tree makes sense to you six months from now. You don't have to write a long explanation about why your non-mutable class subclasses a mutable class, then disables the mutable methods Cons: -object code larger than absolutely necessary -some extra design effort to make sure the non-shared code interacts with the shared code and header files properly [as now it's split into more files and used by two classes] And the 'Pros' win! 42 words to 38 words for 'Cons'! Eli _______________________________________________ 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
