AHA. I am incorrect.
Now in the office, when reviewing my code in the test, I wasn't testing
auto-synthesis of the properties. Now that I am, I can see that
auto-synthesized properties DO create the ivar with the leading underscore.
Stepping back to my original question, the code that I am refactoring has cases
of manual synthesis of properties, some automatically synthesized and some
instance variables declared in the .h or .m interfaces - sometimes.
With regards to understanding what is going on in the 4000 line view
controllers, the areas that were problematic for me were where the instance
variables were declared in the interface as someProperty (or as Someproperty,
ugh) and then the property was declared and manually synthesized with the same
name. So, then trying to wade through the code with identical names for
properties and instance variables and with cases where the variable sometimes
starts with a capital letter, knowing exactly what I was looking at was not
exactly straightforward.
With regards to Uli's comment, I just checked in my test code and if I create a
property in the .h file like so:
@property (nonatomic, strong) NSString *thing;
Don't try to manually synthesize it and then in the .m file, in a method typed:
_thi
Xcode attempts to auto-complete this to _thing. Great.
Completing the code below, and running the test clearly shows that
auto-synthesis of properties does what Uli mentioned.
_thing = @"$";
NSLog(@"self.thing: %@", self.thing);
Console
] self.thing: $
The ivar is preceded with the underscore with auto-synthesis.
What I believe the easiest thing to do in my case is to go through all the
interface declarations of iVars, fix the case and precede them with
underscores, then the property declarations & auto-synthesis of properties. If
I try to rename an ivar declared in the @interface using Refactor, Xcode also
renames the property itself and since I'm looking for a visual difference
between the properties and the ivars, it's just easier this way.
Keeping the declared ivars in the @interfaces keeps a nice visual table of
contents of the ivars the original authors intended. While removing the ivars
and letting Xcode auto-synthesize would be less code, it's also less
descriptive and for this project, I want as much explanation of that's going on
as possible. Parts of it are excellent but other parts, other parts, well….
Now, back to the joys of ad-hoc deployment.
Thanks for the wake up call, UIi!
Cheers,
Alex Zavatone
On May 22, 2015, at 7:05 AM, Alex Zavatone wrote:
>
> On May 22, 2015, at 3:43 AM, Uli Kusterer wrote:
>
>> On 21 May 2015, at 19:55, Quincey Morris
>> <quinceymor...@rivergatesoftware.com> wrote:
>>> On May 21, 2015, at 10:40 , Fritz Anderson <fri...@manoverboard.org> wrote:
>>>>
>>>> I must have misinterpreted the question. I had understood Alex wanted a
>>>> build option to turn off the auto-synthesis of properties, so the compiler
>>>> could complain at every conflation of ivars with @propertys.
>>>
>>> You didn’t misinterpret the question, but there’s no such build setting, so
>>> you have to solve the problem indirectly.
>>>
>>> — You turn on the @synthesize warning.
>>>
>>> — The warning message tells you when you’ve omitted a @synthesize.
>>>
>>> — You add the “new-style” @synthesize:
>>>
>>> @synthesize myProperty = _myProperty;
>>>
>>> — Then all of your old naked ‘myProperty’ ivar references produce compile
>>> errors. QED.
>>>
>>> Changing an old-style ‘@synthesize myProperty;’ to the new style leads to a
>>> similar result, but there’s no initial warning message to lead you there by
>>> the hand.
>>
>> That seems pointless, as auto-synthesis already names the backing ivar it
>> creates _myProperty. Looking at the original thread "Stupid Cocoa question.
>> How can you tell if the object you are looking at is a property or an ivar?”
>> that spawned this, just deleting all the ivar declarations and @synthesize
>> directives might be a better idea, then direct ivar accesses don’t find
>> anything named myProperty and will error out directly. Or synthesize all
>> properties with a name nobody is using yet for the backing ivar, if you have
>> some that use _foo, or mFoo and others that just use foo.
>
> Yeah, but I just tested it this yesterday and it doesn't appear to do that.
>
> It creates an underlying myProperty ivar for a myProperty property, not an
> underlying _myProperty ivar.
>
> I'll send the source when in get in the office in an hour, so you can test
> for yourself if you want to.
>
> Cheers,
> Alex Zavatone
>
>
>
>
>
> _______________________________________________
>
> 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/zav%40mac.com
>
> This email sent to z...@mac.com
_______________________________________________
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
