Re: Redeclaring property types in mutable subclasses
Re: Redeclaring property types in mutable subclasses
- Subject: Re: Redeclaring property types in mutable subclasses
- From: Quincey Morris <email@hidden>
- Date: Mon, 28 Mar 2011 21:28:15 -0700
On Mar 28, 2011, at 20:05, Adam Ernst wrote:
> I have a class with an array property:
>
> @interface Widget : NSObject {}
> @property (retain, readonly) NSArray *gizmos;
> @end
>
> I make a mutable subclass. In addition to making the array property readwrite, I also make it an NSMutableArray for convenience:
>
> @interface MutableWidget : Widget {}
> @property (retain, readwrite) NSMutableArray *gizmos;
> @end
>
> This triggers a warning:
>
> Property 'gizmos' type does not match super class 'Widget' property type
>
> I can understand why this is being triggered. How can I work around it? I could keep it a straight NSArray, but this is cumbersome to edit. Suggestions on how to properly model this in my code?
The pattern I use is:
> @interface MutableWidget : Widget {}
> @property (retain, readwrite) NSMutableArray *mutableGizmos;
> @end
because:
a. There's no practical alternative, I don't think, in terms of keeping the compiler happy AND having the strongest possible compile time type checking.
b. It's often convenient to implement 'mutableGizmos' this way:
> - (NSMutableArray*) mutableGizmos {
> return [self mutableArrayValueForKey: @"gizmos"];
> }
The advantage of this is that it's easy and it's automatically KVO compliant. With a couple of extra lines, you can cache the mutable array property in the mutable getter, and avoid the object creation every time it's called, if you think it's worth the trouble.
c. The caller, therefore, needs to know whether it's making a mutable or immutable reference to the property. It's surprising how often it helps clarify your thinking when you have to decide which one you mean.
Note: With the more recent compiler versions (gcc 4.2, at least), I think you get an error saying that there's no getter for "gizmos" in the mutable subclass, even though the superclass obviously must have one. The easiest way to solve that is to put:
> @dynamic gizmos;
in the subclass, meaning "use the damn setter you've already got".
_______________________________________________
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