On Jul 5, 2016, at 04:36 , Jonathan Taylor <jonathan.tay...@glasgow.ac.uk>
wrote:
>
> @interface ImmutableSettings : NSObject
> {
> BOOL _myFlag;
> }
> @property (readonly) BOOL myFlag;
> @end
>
> @interface MutableSettings : ImmutableSettings
> @property (readwrite) BOOL myFlag;
> @end
>
> @implementation ImmutableSettings
>
> -(id)init
> {
> if (!(self = [super init]))
> return nil;
> _myFlag = true;
> return self;
> }
> @synthesize myFlag = _myFlag;
>
> @end
You have to remember that there’s no magic behind properties. Each class has
(potentially) a getter method, a setter method and an instance variable, which
makes a total of 6 (potential) things across 2 classes. When one is a subclass
of the other, that’s 3 opportunities for conflicts and ambiguities about which
thing is meant at any given place in the code. Different versions of the
compiler detect and complain about different ambiguities.
I’d recommend a different approach, especially if there’s no behavior for the
property other than getting or setting an instance variable (which I assume,
because you’re trying to use synthesis):
— In ImmutableSettings.h, declare “myFlag” as a readonly property. This is its
public definition.
— In ImmutableSettings.m, add a class extension “@interface ImmutableSettings
()” that redeclares “myFlag” as readwrite.
— Synthesize the property in ImmutableSettings.m, producing both getter and
setter. Note, however, that the setter is not available publicly.
— In MutableSettings.h, redeclare “myFlag” as a readwrite property. This makes
it available publicly.
— In MutableSettings.m, say “@dynamic myFlag;” to indicate that the accessors
will be provided at runtime (by the parent class in this case). If you needed
custom behavior in the setter, you could simply provide an override to
setMyFlag: too. Do not synthesize the property in this class.
It may sound weird to make the property (internally) settable in an immutable
class, but the instance variable is always modifiable in the superclass anyway,
so it’s kinda the same thing. Having a private setter there doesn’t really
change anything.
Alternative approach:
If the “myFlag” property is always and forever YES in the superclass, then
don’t synthesize anything in that class, but write a custom setter that simply
return YES. That saves a little bit of memory by not having an instance
variable at all. The just synthesize the readwrite property in the subclass in
the normal way. In the subclass, synthesize the readwrite property normally.
Side note:
Why are you even supporting 32-bit architectures on the Mac? The only good
reason I can think of is if you must still update users running OS X 10.5.
Users of 10.6.8 and above can (and should) use 64-bit versions of apps.
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
