Let's say you have the following property:
@property foo;

Why am I seeing the following line of code to accompany the above
@property directive on various sites in discussions of @synthesize?:

@synthesize foo = _foo; // Obviously this ensures that the backing
// iVar for the foo property is named
// differently and follows the convention
// of the leading '_'.

Why is this @synthesize directive even needed? You don't need it anymore
to synthesize the setter and getter for the foo property. Secondly, if
you omit it, by default, the backing iVar will be the same name as the
property prefixed with an '_'. In other words, by omiting this
@synthesize line, you will automatically get what this @synthesize
directive is doing. It doesn't make sense to have it. Am I missing
something?

What's the reason for this? Have I been reading outdated
websites/discussions and/or people are disseminating incorrect info?
Just wondering if I'm not understanding the use case here. I do already
know that you can use @synthesize to completely rename the iVar so a
detailed discussion/explanation is not necessary. I'm merely wondering
why I'm seeing the above @synthesize directive a lot.

thanks,

jonR

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jon Rossen <jonr17@comcast.net> writes:

Let's say you have the following property:
@property foo;

Why am I seeing the following line of code to accompany the above
@property directive on various sites in discussions of @synthesize?:

@synthesize foo = _foo; // Obviously this ensures that the backing
// iVar for the foo property is named
// differently and follows the convention
// of the leading '_'.

Why is this @synthesize directive even needed? You don't need it anymore
to synthesize the setter and getter for the foo property. Secondly, if you omit it, by default, the backing iVar will be the same name as the
property prefixed with an '_'. In other words, by omiting this @synthesize line, you will automatically get what this @synthesize directive is
doing. It doesn't make sense to have it. Am I missing something?

There are three common reasons.

1. Automatic synthesis doesn't work on 32-bit Mac. You need the explicit @synthesize (or some other substitute) if your code needs to run there.

2. Automatic synthesis is relatively new. Historically you had to
use @synthesize (or some other substitute) on all platforms.

3. Some people distrust the possibility of hidden bugs caused by
automatic synthesis. They prefer to synthesize everything explicitly.
Building with -Werror=objc-missing-property-synthesis enforces that.


--
Greg Parker gparker@apple.com Runtime Wrangler

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/19/2016 8:09 PM, Greg Parker wrote:

Jon Rossen <jonr17@comcast.net> writes:

Let's say you have the following property:
@property foo;

Why am I seeing the following line of code to accompany the above
@property directive on various sites in discussions of @synthesize?:

@synthesize foo = _foo; // Obviously this ensures that the backing
// iVar for the foo property is named
// differently and follows the convention
// of the leading '_'.

Why is this @synthesize directive even needed? You don't need it anymore
to synthesize the setter and getter for the foo property. Secondly, if you >> omit it, by default, the backing iVar will be the same name as the
property prefixed with an '_'. In other words, by omiting this @synthesize >> line, you will automatically get what this @synthesize directive is
doing. It doesn't make sense to have it. Am I missing something?

There are three common reasons.

1. Automatic synthesis doesn't work on 32-bit Mac. You need the explicit @synthesize (or some other substitute) if your code needs to run there.

2. Automatic synthesis is relatively new. Historically you had to
use @synthesize (or some other substitute) on all platforms.

3. Some people distrust the possibility of hidden bugs caused by
automatic synthesis. They prefer to synthesize everything explicitly. Building with -Werror=objc-missing-property-synthesis enforces that.

Greg,

Thanks very much for this detailed answer. I find it interesting that automatic synthesis doesn't work on 32 bit Macs.

For #2 in your list (the newness of the feature), could that perhaps
suggest that some of the discussions I've been reading were from a few
years back? Sometimes I forget to check the dates on the site. And for discussions that were later on, after automatic synthesis was
implemented, could it also be that the people who post on the sites may
not be keeping up with latest features?

Another reason I was thinking of after my original post was code
readability. Apart from the distrust issue you cited in your #3, could
it be that some people like to explicitly synthesize because it makes
their code more self-documenting and easier for others to read?

thanks again,

jonR

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jon Rossen <jonr17@comcast.net> writes:

Thanks very much for this detailed answer. I find it interesting that automatic synthesis doesn't work on 32 bit Macs.

How is planned obsolescence interesting?

It's despicable, possibly understandable on the part of a capitalist corporations whose sole purpose is to accumulate monetary profits.
But how can it be interesting? It's trivial evil.


--
__Pascal Bourguignon__ http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/21/2016 1:23 PM, Pascal J. Bourguignon wrote:

Jon Rossen <jonr17@comcast.net> writes:

Thanks very much for this detailed answer. I find it interesting that
automatic synthesis doesn't work on 32 bit Macs.

How is planned obsolescence interesting?

It's despicable, possibly understandable on the part of a capitalist corporations whose sole purpose is to accumulate monetary profits.
But how can it be interesting? It's trivial evil.

It was interesting to me because it was a factoid that I didn't know
about. So much of the crap I read online is info that I either already
know or have already heard about. That's it. I wasn't condoning any of
the evil economic practices that it represents that you were railing
about. Now, go take your meds! :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

Jon Rossen <jonr17@comcast.net> writes:

Thanks very much for this detailed answer. I find it interesting that
automatic synthesis doesn't work on 32 bit Macs.

How is planned obsolescence interesting?

It's despicable, possibly understandable on the part of a capitalist corporations whose sole purpose is to accumulate monetary profits.
But how can it be interesting? It's trivial evil.

It's not planned obsolescence. It's a technical limitation.

The Objective-C ABI used on 32-bit Mac does not and cannot support
non-fragile ivars. (I spent almost a year trying. It just can't be done
with good performance and good binary compatibility.)

If your ivars are fragile then automatic property synthesis is unusably
risky. It is too easy to do something that looks safe but actually
introduces binary compatibility bugs by changing your ivar layout.

We did support it internally, briefly. Literally nobody was able to use
it correctly. We removed it.


--
Greg Parker gparker@apple.com Runtime Wrangler

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Greg Parker <gparker@apple.com> writes:

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

Jon Rossen <jonr17@comcast.net> writes:

Thanks very much for this detailed answer. I find it interesting that
automatic synthesis doesn't work on 32 bit Macs.

How is planned obsolescence interesting?

It's despicable, possibly understandable on the part of a capitalist
corporations whose sole purpose is to accumulate monetary profits.
But how can it be interesting? It's trivial evil.

It's not planned obsolescence. It's a technical limitation.

The Objective-C ABI used on 32-bit Mac does not and cannot support non-fragile ivars. (I spent almost a year trying. It just can't be done
with good performance and good binary compatibility.)

If your ivars are fragile then automatic property synthesis is unusably risky. It is too easy to do something that looks safe but actually
introduces binary compatibility bugs by changing your ivar layout.

We did support it internally, briefly. Literally nobody was able to use
it correctly. We removed it.

Sorry, I tend to dismiss binary compatibility considerations, since I
use a lot of freedom software where the source is always available.

You are indeed in a more difficult situation.


--
__Pascal Bourguignon__

Croire en l'histoire officielle, c'est croire des criminels sur parole.
-- Simone WEIL (1909-1943) philosophe Fran�aise.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)