Re: Property synthesis trouble - 32 vs 64 bit builds
Re: Property synthesis trouble - 32 vs 64 bit builds
- Subject: Re: Property synthesis trouble - 32 vs 64 bit builds
- From: Jonathan Taylor <email@hidden>
- Date: Tue, 05 Jul 2016 22:10:11 +0100
Thanks everyone for your replies - some responses below:
On 5 Jul 2016, at 20:55, Greg Parker <email@hidden> 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 <email@hidden> 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 (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