On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote:

> On Jun 1, 2015, at 11:43 PM, Britt Durbrow 
> <bdurb...@rattlesnakehillsoftworks.com> 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 <cocoa...@charlessoft.com 
>>> <mailto:cocoa...@charlessoft.com>> 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 (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

Reply via email to