Thanks everyone for your replies - some responses below: On 5 Jul 2016, at 20:55, Greg Parker <gpar...@apple.com> wrote: > A synthesized property must use one of the following types of storage: > 1. An ivar in that class that @synthesize creates. > 2. An ivar in that class that you defined yourself. > > @synthesize on 32-bit macOS doesn't support #1. The problem is that 32-bit > macOS doesn't support non-fragile ivars. Allowing @synthesize to create ivars > would make it too easy to accidentally change ivar layout and break > compatibility. > > No platform allows @synthesize to bind to a superclass ivar. That would make > it too easy to accidentally bind to an unrelated superclass ivar when you > really wanted to create a new ivar.
That last statement is a surprise to me. I had believed that the 32-bit code I posted was doing just that - MutableSettings binding its property to the ivar in ImmutableSettings. Certainly it's not clear to me how that statement *and* your statement that #1 is not supported on 32-bit could both be true (there is no backing ivar that I declare in the mutable subclass). I also ~think~ the code is working correctly on a 32-bit platform (and has been for several years). I'm not meaning to be argumentative, just trying to get my head around this :-) On 5 Jul 2016, at 18:12, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote: > 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): > [...] > 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. Interesting. It does indeed sound weird, but I agree that it shouldn't actually be any different to what I'm currently doing. I might just give that a go! Does this approach have any specific advantages compared to the approach suggested by Keary (i.e. basically don't do any synthesis, and just write a getter in the base class and a setter in the subclass)? > 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. Quicktime. My code has been 32-bit only since I first wrote it, because I make use of the APIs in QuickTime/ImageCompression.h for encoding movies. It's my understanding (as of last time I checked) that no equivalent functionality is available in the newer APIs. That, plus a big dose of "if it ain't broke, don't fix it", as a scientist for whom this Cocoa application of mine is a very helpful tool for me and my colleagues, but is just a means to an end rather than a product in its own right. I have only now started looking at 64 bit (knowing I am losing the quicktime functionality) because I wanted to look at interfacing with libraries that are 64-bit only. _______________________________________________ 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
