Re: Looking at self = [super init].
Re: Looking at self = [super init].
- Subject: Re: Looking at self = [super init].
- From: Alex Zavatone <email@hidden>
- Date: Wed, 03 Jun 2015 09:02:08 -0400
On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote:
> On Jun 1, 2015, at 11:43 PM, Britt Durbrow <email@hidden> wrote:
>>
>> Although I have the luxury of requiring modern runtime capable systems, some people do still have to target the old runtime…
>
> ARC requires the modern runtime, which has pretty much caused the old one to drop off the map for most people, I think.
>
>> Also, FWIW the modern runtime only handles same-named instance variables that are privately declared; same-named variables declared in an @interface section will conflict even on the modern runtime.
>
> Variables declared in an @interface section trigger a compiler warning:
>
> warning: declaration of instance variables in the interface is deprecated [-Wobjc-interface-ivars]
>
>> Oh, and there’s a nifty warning that’s thrown as soon as you try to declare a local variable of the same name as an instance variable.
>
OK. This is very important to me. Where in the project can I set these flags so that they are project wide (or remove these flags) so that we get those warnings. Project > Target > Build Settings - But under which section?
I have a metric crapload of these to sort out as time permits and would LOVE to turn on these warning flags so I can bring this part of project up to 2012 standards, and then maybe eventually to 2015 standards.
But one step at a time.
> That doesn’t help if I’m looking at some code that someone else wrote, or code that I wrote 5 years ago, noticing a variable name being used somewhere, and having to hunt around for the declaration to figure out whether it’s a local variable, an instance variable, or something stupid like a global or something.
This is the exact issue that I have in my project where some ivars are declared in the @interface with the same name as the @property.
Sadly, within Xcode, there is no easy convention (like color coding the difference between the two) to show the difference between the an ivar and an @property with the same name within the class files.
>
>>> On Jun 1, 2015, at 3:14 PM, Charles Srstka <email@hidden <mailto:email@hidden>> wrote:
>>
>>>
>>> Non-underscored ivars vs. local variables, however, are not obvious at all, especially if the method is large.
Yeah, I think I mentioned this last week and it is the cause of great pain in my current project. Especially when you have 4 thousand line view controllers that include other view controllers and have a delegate that is an other view controller.
>> In modern versions of Xcode at least, if I don’t know exactly what I’m looking at, the answer is just a command-click away… :-)
Sadly, in my situation, that generally only gets me 1/4 of the way there.
> That can be handy, when it works. Sometimes it doesn’t (particularly when you’re using Swift, in which command-click usually just brings up an endless circular progress indicator).
>
>> Also, the syntax highlighting does render (at least on my setup) in different colors for local variables and instance variables.
>
> That can be handy, if you’re not colorblind. If you are, the coloring isn’t much help.
That may be nice, but there is still NO DIFFERENCE AT ALL between the colors for instance variables and properties (or way to set them) within Xcode.
Unless there's something I missed. Can we add our own coloring rules?
Really glad we're touching in these topics. These are me helping wrangle my project immensely.
Best,
Alex Zavatone
_______________________________________________
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