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

Reply via email to