Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Britt Durbrow]

> On Jun 3, 2015, at 11:30 AM, Mark Wright  wrote:
> 
> For what it’s worth, I’ve never had that problem either.  Most of the time 
> self.whatever is used for property access, _whatever is used for ivar access 
> and that’s about it.

Yup. This is what I meant about properties vs ivars being obvious from context: 
the only way to do a property access is by causing a message send; and there 
are only three direct ways to do that in Objective-C: somePointer.accessor 
(i.e, dot notation); [somePointer accessor] and [somePointer 
setAccessor:aNewValueGoesHere]; and a direct call to objc_msgSend(). 

All other forms are direct variable access: either globals, locals, or instance 
variables.

In other words:

@inteface foo : NSObject
@property(nonatomic) int bar;
-(void)doSomething;
@end

@implementation foo
{
int bar;
};

-(int)bar
{
return bar;
};

-(void)setBar:(int)new_BarValue
{
bar=new_BarValue;
};

-(void)doSomething
{
bar=12345;  // Direct access to bar

self.bar=12345  // Going thru the property’s setter
[self setBar:6789];
if([self bar]==6789)
puts(“Yay, it’s still what I set it to!\n”);

int baz;// Obviously a local

baz=123 // Direct access

self.baz=456;   // Compile error here; because baz is a local, 
not a property. Other obvious error patterns left as an exercise for the 
reader. :-)
};

@end

// Note: thoroughly compiled and tested in Mail.app ;-) 
___

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

Re: Questions about NSPopupButtonCell and NSBrowser

[Graham Cox]

> On 4 Jun 2015, at 10:20 am, Frank D. Engel, Jr.  wrote:
> 
> I am wondering if the browser is actually caching an image of the cells in 
> the second column when I switch away, then just displaying that without 
> actually recreating the cells in the second column until it needs one of them 
> for something?  That might explain the behavior I am seeing, and may be a 
> sensible optimization in most cases, but in this instance it is not very 
> helpful for my particular application.


Sounds very doubtful.

[self controlView] is probably unreliable in your cell - you might want to 
check it. But even if it’s correct (being the NSMatrix for the browser column) 
invalidating the whole thing is going to be very sub-performant (though should 
work).

Note that NSBrowser, unlike a NSTableView, allocates one cell per row within a 
NSMatrix - it does not reuse and redisplay a single cell.

—Graham



___

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

Re: Questions about NSPopupButtonCell and NSBrowser

[Frank D. Engel, Jr.]

After all of this, I finally at least partially solved this one.

I added a line of code to run each time that method is called.

It wasn't being called most of the time.  I found where I was calling 
this and changed the code a bit to use a binding created by code, and 
now it is almost working.


The images are in the second column of the browser (these columns are 
actually the same A and B as the NSPopupButtonCell question I still am 
trying to figure out - the first column shows A, and second column shows 
the B's for that A).


If I arrange for one of them to start changing while I have a particular 
A selected, it works as long as I keep that A selected. When I switch to 
a different A then switch back while it should still be changing, it is 
"frozen" - the image appears from wherever it was when I switched away, 
and my setImage method is not being called.  When I select a B within 
that A, it starts being called again.



I am wondering if the browser is actually caching an image of the cells 
in the second column when I switch away, then just displaying that 
without actually recreating the cells in the second column until it 
needs one of them for something?  That might explain the behavior I am 
seeing, and may be a sensible optimization in most cases, but in this 
instance it is not very helpful for my particular application.




On 6/3/2015 19:52, Frank D. Engel, Jr. wrote:
I based my code on one of Apple's examples and had tried using 
NSBrowserCell but was not able to get that working; I assume there is 
some reason why Apple chose to use NSTextFieldCell in their example 
and I followed suit.



Currently, I have this coded - I had tried several variations to force 
the redraw and landed here but it still is not working consistently.


- (void)setImage:(NSImage *)newImage
{
//[newImage retain];
//[img release];
img = newImage;
[[self controlView] setNeedsDisplay:YES];
}



On 6/3/2015 19:39, Graham Cox wrote:
On 4 Jun 2015, at 7:29 am, Frank D. Engel, Jr.  
wrote:


Now what I am hoping is the simpler one:

I have a custom subclass of NSTextFieldCell which I am using to show 
an icon in an NSBrowser.  The icon image is being generated 
dynamically by a method in my subclass and I want it to change more 
or less in "real time" as a bound value changes.  I have that almost 
working, but the one problem is that it doesn't refresh when I need 
it to.


Is there some way I can "force" a browser cell to redraw its image, 
short of redrawing the entire browser or window?  The text isn't 
changing, just the icon, but I'd settle for redrawing the cell...


I've tried a number of things to get this working and it seems I 
keep coming up short.


NSBrowser normally uses NSBrowserCell to draw its content. That class 
has a -setImage: method which presumably knows how to mark the 
correct part of its host view as needing display.


If you have to use a different cell class, then you’ll need to figure 
out how to do the same. The cell is part of a 1-column NSMatrix which 
has methods to return the rect occupied by a given row, so given that 
you can call -setNeedsDisplayInRect: on the matrix itself. Useful 
methods there are -[NSMatrix getRow:column:ofCell:] and -[NSMatrix 
cellFrameAtRow:column:];



hth,

—Graham






___

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/fde101%40fjrhome.net

This email sent to fde...@fjrhome.net



___

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

Re: Questions about NSPopupButtonCell and NSBrowser

[Frank D. Engel, Jr.]

I based my code on one of Apple's examples and had tried using 
NSBrowserCell but was not able to get that working; I assume there is 
some reason why Apple chose to use NSTextFieldCell in their example and 
I followed suit.



Currently, I have this coded - I had tried several variations to force 
the redraw and landed here but it still is not working consistently.


- (void)setImage:(NSImage *)newImage
{
//[newImage retain];
//[img release];
img = newImage;
[[self controlView] setNeedsDisplay:YES];
}



On 6/3/2015 19:39, Graham Cox wrote:

On 4 Jun 2015, at 7:29 am, Frank D. Engel, Jr.  wrote:

Now what I am hoping is the simpler one:

I have a custom subclass of NSTextFieldCell which I am using to show an icon in an 
NSBrowser.  The icon image is being generated dynamically by a method in my subclass and 
I want it to change more or less in "real time" as a bound value changes.  I 
have that almost working, but the one problem is that it doesn't refresh when I need it 
to.

Is there some way I can "force" a browser cell to redraw its image, short of 
redrawing the entire browser or window?  The text isn't changing, just the icon, but I'd 
settle for redrawing the cell...

I've tried a number of things to get this working and it seems I keep coming up 
short.


NSBrowser normally uses NSBrowserCell to draw its content. That class has a 
-setImage: method which presumably knows how to mark the correct part of its 
host view as needing display.

If you have to use a different cell class, then you’ll need to figure out how 
to do the same. The cell is part of a 1-column NSMatrix which has methods to 
return the rect occupied by a given row, so given that you can call 
-setNeedsDisplayInRect: on the matrix itself. Useful methods there are 
-[NSMatrix getRow:column:ofCell:] and -[NSMatrix cellFrameAtRow:column:];


hth,

—Graham






___

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

Re: Questions about NSPopupButtonCell and NSBrowser

[Graham Cox]

> On 4 Jun 2015, at 7:29 am, Frank D. Engel, Jr.  wrote:
> 
> Now what I am hoping is the simpler one:
> 
> I have a custom subclass of NSTextFieldCell which I am using to show an icon 
> in an NSBrowser.  The icon image is being generated dynamically by a method 
> in my subclass and I want it to change more or less in "real time" as a bound 
> value changes.  I have that almost working, but the one problem is that it 
> doesn't refresh when I need it to.
> 
> Is there some way I can "force" a browser cell to redraw its image, short of 
> redrawing the entire browser or window?  The text isn't changing, just the 
> icon, but I'd settle for redrawing the cell...
> 
> I've tried a number of things to get this working and it seems I keep coming 
> up short.


NSBrowser normally uses NSBrowserCell to draw its content. That class has a 
-setImage: method which presumably knows how to mark the correct part of its 
host view as needing display.

If you have to use a different cell class, then you’ll need to figure out how 
to do the same. The cell is part of a 1-column NSMatrix which has methods to 
return the rect occupied by a given row, so given that you can call 
-setNeedsDisplayInRect: on the matrix itself. Useful methods there are 
-[NSMatrix getRow:column:ofCell:] and -[NSMatrix cellFrameAtRow:column:];


hth,

—Graham




___

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

Questions about NSPopupButtonCell and NSBrowser

[Frank D. Engel, Jr.]

I have two questions I'm hoping I can get some advice on...


First the complicated one:


I have an NSTableView (cell-based) in which I am trying to rig two 
columns with NSPopupButtonCell - the selection in the first one 
determines the possible values of the second.


This is part of a document-based core data setup; the data model has 
three entities that are relevant to this activity; for my purposes here 
I will call the first two A and B.  There is a one-to-many relationship 
from A to B, such that an A has - let's call them "kids", and the 
reverse would be the "parent" of a B.  Every B is tied to an A; an A 
will usually have one or more B's.


The individual rows in the NSTableView are members of another entity, 
which I herein call E, which has a many-to-one relationship to a B (any 
given E has exactly one B tied to it, call it the "b" of E; but several 
E's can be tied to the same B).


I created a custom NSManagedObject subclass which implements a method, 
call it "a", which returns "b.parent" - the A of the B that the E is 
connected to.



Attempt at a picture:

A -> B  <- E
| -> B
| -> B  <-- E
 |- E



The first NSPopupButtonCell should have a list of all of the A's and let 
me pick one - that much I have working using bindings:


Content: aController.arrangedObjects
Content Values: aController.arrangedObjects.name
Selected Object: eController.arrangedObjects.a


Now I'm trying to figure out how to set up the second NSPopupButtonCell 
to list all of the B's whose parent is A (so, a.kids) with the "b" of E 
being the selected one.


I can't very well use another NSArrayController to do this (at least not 
via IB?) since the list may be different for each row of the table.


I'm a bit confused on how to rig this one and I'm not finding any clear 
documentation to help with this.



Does anyone have any suggestions on how to make this work?  I don't want 
to just list all of the B's since there could be thousands of them and 
it would be WAY too much to navigate through without narrowing it down 
first (thus the first popup list...)




Now what I am hoping is the simpler one:

I have a custom subclass of NSTextFieldCell which I am using to show an 
icon in an NSBrowser.  The icon image is being generated dynamically by 
a method in my subclass and I want it to change more or less in "real 
time" as a bound value changes.  I have that almost working, but the one 
problem is that it doesn't refresh when I need it to.


Is there some way I can "force" a browser cell to redraw its image, 
short of redrawing the entire browser or window?  The text isn't 
changing, just the icon, but I'd settle for redrawing the cell...


I've tried a number of things to get this working and it seems I keep 
coming up short.




Thank you!

___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Mark Wright]

> On 03 Jun 2015, at 19:54, Alex Zavatone  wrote:
> 
> 
> On Jun 3, 2015, at 2:30 PM, Mark Wright wrote:
> 
>> The only potential problem is ivars that don’t have the leading underscore.
> 
> My project has 377 of them.  All named the same as the property, if there is 
> a property to begin with.   That's why I'm walking down this fun little road. 
>  


Yeah, tis dog work and there’s nothing much to be done but get stuck in.  I 
don’t know if it’ll help but this is how I’d initially tackle a wholesale 
ivar-to-property refactor manually:

Step 1  -  Cut and paste all ivars out of header and into @implementation block 
- should be no change from compiler’s point of view.  This takes the header 
file out of the equation.

Step 2  -  Comment out or remove any explicit @synthesize statements.

Step 3  -  Now select each ivar in turn in the newly pasted block and ‘Edit All 
in Scope’ (ctrl + command + E).  This will select them throughout the entire 
file.  Add the leading underscore so that they conform to the expected pattern.

Step 4  -  Now that they will mirror their property if it exists, one-by-one 
comment them out and see if any compiler errors show up.  If not then the 
property is intact and the ivar is likely not needed.  If there are errors then 
maybe a property needs creating for that one or the ivar can stay depending on 
its role in the class.




___

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

Re: Looking at self = [super init].

[Charles Srstka]

> On Jun 3, 2015, at 8:02 AM, Alex Zavatone  wrote:
> 
> On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote:
> 
>> On Jun 1, 2015, at 11:43 PM, Britt Durbrow 
>>  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.

What I do is to put -Weverything in “Other Warning Flags”. Then, I add -Wno 
flags for all the ones I want to turn off (and trust me, there’ll be a bunch of 
those). Then, at the end, you have a string that you can just copy and paste 
into your new projects and get the warnings set up exactly how you like them, 
and you’ll get new warnings as soon as they’re added to Clang.

There is one hitch here, which is that you have to make sure there aren’t any 
flags set to “No” in the build settings for Warnings, because each one of those 
adds a -Wno of its own to the build command.

Charles

___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Alex Zavatone]

On Jun 3, 2015, at 2:30 PM, Mark Wright wrote:

> The only potential problem is ivars that don’t have the leading underscore.

My project has 377 of them.  All named the same as the property, if there is a 
property to begin with.   That's why I'm walking down this fun little road.  
___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Mark Wright]

> On 03 Jun 2015, at 18:59, Uli Kusterer  wrote:
> 
> On 03 Jun 2015, at 19:09, Alex Zavatone  wrote:
>> On Jun 3, 2015, at 12:59 PM, Uli Kusterer wrote:
>> 
>>> So you're not supposed to use the underscore convention even for your 
>>> private ivars, as Apple could add secret stuff to NSObject or any other 
>>> base class you'd collide with.
>>> 
>>> -- Uli
>> 
>> So, how are we expected to tell the private/public/ivar/property difference 
>> between all these variables we have to look at all day in an easy, clear and 
>> straightforward manner that doesn't require unnecessary thinking?
> 
> I've never had a problem telling that difference, so I can't answer that 
> question for you. If an object is complex enough that this becomes an issue, 
> I'd probably split it up into several objects so it becomes easier and more 
> obvious to grasp.
> 
> -- Uli


For what it’s worth, I’ve never had that problem either.  Most of the time 
self.whatever is used for property access, _whatever is used for ivar access 
and that’s about it.  Public or private property doesn’t matter within the .m 
file since they’re both properties of the class.  Which is which is a result of 
the overarching design of the class at a higher level.

The rest is taken care of within the IDE in some manner or can be quickly 
checked if really needed.

The only potential problem is ivars that don’t have the leading underscore.  My 
own declared ivars *are* declared with the underscore so I typically don’t see 
that problem (the IDE’s colouring helps here I suppose since they tend to look 
different).  I believe Uli is mistaken on this point, I’m pretty sure Apple 
actually recommends prefixing your own ivars in this manner (hence the way auto 
property synthesis works), it’s *methods* that generally shouldn’t be prefixed 
with an underscore (but I do that on occasion too since the naming is generally 
specific enough to render collisions vanishingly unlikely).



___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Alex Zavatone]

On Jun 3, 2015, at 1:59 PM, Uli Kusterer wrote:

> On 03 Jun 2015, at 19:09, Alex Zavatone  wrote:
>> On Jun 3, 2015, at 12:59 PM, Uli Kusterer wrote:
>> 
>>> So you're not supposed to use the underscore convention even for your 
>>> private ivars, as Apple could add secret stuff to NSObject or any other 
>>> base class you'd collide with.
>>> 
>>> -- Uli
>> 
>> So, how are we expected to tell the private/public/ivar/property difference 
>> between all these variables we have to look at all day in an easy, clear and 
>> straightforward manner that doesn't require unnecessary thinking?
> 
> I've never had a problem telling that difference, so I can't answer that 
> question for you. If an object is complex enough that this becomes an issue, 
> I'd probably split it up into several objects so it becomes easier and more 
> obvious to grasp.
> 
> -- Uli

Well, I wonder if starting private properties with a p as in pSomeAwesomeThing 
would be a decent-enough convention to start, because then an ivar for a 
private property would be _pSomeAwesomeThing.

This would leave public properties without any lowercase p (followed by a 
capital letter that starts the next word) and the ivar would be the same, but 
just starting with the _.

That would give us:

Public property:labelString
Public property's ivar: _labelString
Private property:   pLabelString
Private property's ivar:_pLabelString


Does this seem to be a decent enough and not unweildy convention?  While it 
wouldn't show any difference between a local or a parameter, it would certainly 
clarify the scope of these 4 cases.

Is this enough, or should we also take into effect locals and parameters?  For 
locals, we could use my as a prefix since they would be local to the method, 
but that could end up as a PITA.

Also, how would this conflict with the recommended is prefix for booleans, if 
at all?

Thanks much, man.

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Uli Kusterer]

On 03 Jun 2015, at 19:09, Alex Zavatone  wrote:
> On Jun 3, 2015, at 12:59 PM, Uli Kusterer wrote:
> 
>> So you're not supposed to use the underscore convention even for your 
>> private ivars, as Apple could add secret stuff to NSObject or any other base 
>> class you'd collide with.
>> 
>> -- Uli
> 
> So, how are we expected to tell the private/public/ivar/property difference 
> between all these variables we have to look at all day in an easy, clear and 
> straightforward manner that doesn't require unnecessary thinking?

 I've never had a problem telling that difference, so I can't answer that 
question for you. If an object is complex enough that this becomes an issue, 
I'd probably split it up into several objects so it becomes easier and more 
obvious to grasp.

-- Uli
___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Uli Kusterer]

On 03 Jun 2015, at 19:06, Alex Zavatone  wrote:
> On Jun 3, 2015, at 12:46 PM, Mark Wright wrote:
> 
>> This is important and is all about *scope*.
>> 
>> A class’s properties are only public if they’re in the header.
> 
> Exactly.
> 
> With that said, why do we not have a convention with properties declared 
> within the .m file for showing that they are private but not ivars?
> 
> If we do, what is it?

It's historical. In ye olde days (32-bit MacOS and NeXT before it), the 
compiler needed to know what ivars an object had to be able to allocate memory 
for it. These days (i.e. on the "modern runtime" that you have on 64-bit Mac 
and all flavors of iOS), it doesn't need that information anymore (the size 
needed for an object's ivar storage and, more importantly, the offsets of 
individual ivars inside the storage is conveyed differently).

Now that that isn't needed anymore, Apple recommends declaring properties that 
clients of your class are supposed to mess with in the header, the others (e.g. 
ones that are an implementation detail or only of interest to subclassers) in 
your implementation or a header that you indicate as containing stuff for these 
purposes (e.g. by naming it MyClassSubclassers.h).

The only convention I know that some programmers use is a prefix, usually the 
same as the class prefix, but lowercase and with an underscore separating it 
from the method name (e.g. uli_frobnitzTheFrobozz:). The reason few people use 
this is because most people find it harder to read in method invocations, and 
most method names are probably expressive enough not to make sense for the 
usual NSObject, UIView or UIViewController base classes, so collisions are 
unlikely. Also because they look a bit daft in setters when used with 
properties (like setUli_frobnitz:).

-- Uli
___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Alex Zavatone]

On Jun 3, 2015, at 12:59 PM, Uli Kusterer wrote:

> So you're not supposed to use the underscore convention even for your private 
> ivars, as Apple could add secret stuff to NSObject or any other base class 
> you'd collide with.
> 
> -- Uli

So, how are we expected to tell the private/public/ivar/property difference 
between all these variables we have to look at all day in an easy, clear and 
straightforward manner that doesn't require unnecessary thinking?

And one that is compatible with your concern, too.

??
___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Alex Zavatone]

On Jun 3, 2015, at 12:46 PM, Mark Wright wrote:

> This is important and is all about *scope*.
> 
> A class’s properties are only public if they’re in the header.

Exactly.

With that said, why do we not have a convention with properties declared within 
the .m file for showing that they are private but not ivars?

If we do, what is it?

If we don't, let's think about this and submit a well thought out standard for 
this and let the list suss it out, then we start using it.

Currently, I know of no convention that is in common use for this and Xcode's 
code coloring doesn't help us to see the differences between:

public properties
private ivars that back public properties
private properties
private ivars that back private properties

Am I missing anything here?



As food for thought, back in late last century, we had this wonderful 
multimedia tool known as Macromedia Director and a very LUA/Hypertalk/Smalltalk 
language in it called Lingo.

Within this tokenized, object oriented scripting language, we have properties 
that were scoped to the script(class) they were created in, globals and locals. 
 

Parameters also mattered too, because you would have to tell the difference 
between them and locals.

That's it.

We took the approach of naming each global starting with a lowercase g, like 
gSoundManager.

Likewise, properties always started with a lowercase p, like pSoundChannel.

Within functions, I wanted to see the difference between my passed in 
parameters and my locals.  To show that difference, each local started with a 
lowercase my, as in myCurrentSoundChannel.

This approach made determining every variable's scope really, really, really a 
no brainer.  Simply by eveballing each variable, I wouldn't have to waste more 
than one brain cell cycle to determine out what its scope was and what it 
applied to and where it could be used.

It ended up being REALLY NICE, because you could just look at the code and 
"get" a lot of how and where the data structures applied to the program they 
were in.  The idea was "you didn't have to think to determine the variable's 
purpose and area of affect(scope)".  

I don't know about the seasoned Objective-C veterans, but I'd sure love to see 
some standard approaches like that here in Objective-C.


Sooo, anyone have any good suggestions to get us there?  Anyone?  Anyone?  
Bueller?

Anyone?
___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Uli Kusterer]

> On 03 Jun 2015, at 18:46, Mark Wright  wrote:
> 
> 
>> On 03 Jun 2015, at 17:08, Alex Zavatone  wrote:
>> 
>> 
>> One point I haven't looked at is, "if @properties are declared within the 
>> @implementation or the class extension, are they private?  And if so, 
>> shouldn't they be preceded with an underscore and in that case, what does 
>> that make the ivar look like"?
>> 
>> How are we to name private properties in modern Objective-C even though 
>> properties were/are inherently public (as I understand it)
>> 
> 
> This is important and is all about *scope*.
> 
> A class’s properties are only public if they’re in the header.

I think the OP's question was more about the naming conventions to avoid 
collisions (like not naming methods with a leading underscore). That hasn't 
changed.

Getters and setters of properties (whether explicitly declared or by defining a 
property that synthesizes them) should not start with an underscore (For 
synthesized setters that's near-impossible, but for getters, defining a 
property whose name starts with an underscore would do the job, so don't do 
that), and since they're all registered in the same tables as all public 
methods, they're only conceptually private, but still outwardly accessible 
using valueForKey: etc..

Note that the naming rules are for keeping Apple's and your code from 
colliding, and for making your properties etc. work with frameworks 
conventions. So you're not supposed to use the underscore convention even for 
your private ivars, as Apple could add secret stuff to NSObject or any other 
base class you'd collide with.

-- Uli
___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Mark Wright]

> On 03 Jun 2015, at 17:08, Alex Zavatone  wrote:
> 
> 
> One point I haven't looked at is, "if @properties are declared within the 
> @implementation or the class extension, are they private?  And if so, 
> shouldn't they be preceded with an underscore and in that case, what does 
> that make the ivar look like"?
> 
> How are we to name private properties in modern Objective-C even though 
> properties were/are inherently public (as I understand it)
> 

This is important and is all about *scope*.

A class’s properties are only public if they’re in the header.

The .h header file describes the class’s public facing interface.  You might 
consider this the ‘outside’ of the class.

The .m implementation file describes the class’s internal private inner 
workings.  You might consider this the ‘inside’ of the class.

The header is used to advertise what is accessible to other objects (often 
called ‘clients’).  This being properties that can be set, properties that can 
be queried and methods that can be called (really ‘sending messages’).

The implementation however is considered completely out of bounds and is 
private to the class.  So, if you declare @properties inside the 
@implementation then, yes, they are private.  However, you don’t need any 
special naming conventions or extra underscores or anything like that, *they’re 
only accessible by code inside the .m file itself.*

Now, as the programmer yourself, the code you’re writing inside the .m file is 
the same sort of code you’re writing everywhere else so it’s up to you to 
always keep in mind this concept of scope.

An example: if you want an internal object that you might be wanting to get and 
set frequently *but is not part of the public facing side of the class* you’d 
declare a @property just for use inside the class.  On the other hand, maybe 
there’s an object you need inside the class but you only set it up once, 
perhaps an NSUndoManager for example, then there’s no point making it a 
property so instead you can declare this as an ivar in the @implementation 
block, set it up in the init method and just refer to it whenever it’s needed.





___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Alex Zavatone]

Here's what I found to be great places to start from within one of Apple's docs.

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf

Essential reading
Page 16:

Page 43: 

Page 73: Use Class Extensions to Hide Private Information




On Jun 3, 2015, at 12:24 PM, Bernard Desgraupes wrote:

> 
> My question was unclear. I was asking about _where_ they should be declared. 
> I guess they remain in the @interface.
> 
> 
> Le 3 juin 2015 à 18:11, Mark+Vron  a écrit :
> 
>>> On 03 Jun 2015, at 16:27, Bernard Desgraupes  wrote:
>>> 
>>> 
>>> What about the @property declarations in the new scheme ?
>>> 
>> 
>> I’m not sure what you’re asking, @properties are a big part of the 'new 
>> way'… 
>> 
>> This is not about properties though, just about the notion of moving ivars 
>> out of the class @interface and (if still needed) into the @implementation 
>> or class extension.  There’s a clang warning that can be enabled to help you 
>> if desired: -Wobjc-interface-ivars
>> 
>> 
>> 
>>> 
>>> Le 3 juin 2015 à 17:15, Mark Wright  a écrit :
>>> 
 Sorry, yes, I misread the initial paragraph that mentions the 
 @implementation block.  I actually meant implementation *file* since 
 that’s typically where the class extension @interface is declared (it 
 extends the class internally).
 
 However, as you’ve surmised, all this talk of clang warnings regarding 
 this is directly related to the primary *class interface* which is 
 typically declared in the header file.  This is the class interface:
 
 @interface SubClass : ParentClass
 ….
 @end
 
 The idea is to end the old ways of declaring ivars in the header and move 
 them into the implementation where they belong (they’re private to the 
 class).
 
 
 
 
> On 03 Jun 2015, at 16:02, Alex Zavatone  wrote:
> 
> 
> On Jun 3, 2015, at 10:41 AM, David Duncan wrote:
> 
>> There are 3 ways to add ivars to a class. The traditional way:
>> 
>> @interface Foo {
>>  id _bar;
>> }
>> 
>> And 2 new ways:
>> 
>> @interface Foo() { // Class extension, note the ()
>>  id _baz;
>> }
> 
> Ahhh.  Completely missed that.  Haven't seen it explained that 
> clearly in a morning of surfing.
> 
> So, running a quick test using the clang pragma for 
> -Wobjc-interface-ivars, in both the .h and .m files of a class this 
> clarifies the Apple and Clang documentation quite a bit.
> 
> In the 3 cases you outlined for declaring iVars, Clang ONLY warns about 
> declaring the ivars within the @interface parens of @interface which is 
> generally within the header file.
> 
> Both other cases (the two new ways of class extension, @interface stuff() 
> {} and @implementation stuff {} ) do not upset Clang at all.
> 
> So, generally, the rule comes down to "don't declare ivars within the 
> @interface that is probably within your .h file but if you need to (you 
> should use properties instead), you can within the class extension and 
> @implementation."
> 
> Does this sound like a proper explanation?
> 
> Thanks much, David.
> 
> 
>> @implementation Foo { // Implementation block.
>>  id _faz;
>> }
>> 
> 
> 
>>> On Jun 3, 2015, at 7:32 AM, Alex Zavatone  wrote:
>>> 
>>> Maybe I should have included the text above it.
>>> 
>>> "It's also possible to use a class extension to add custom instance 
>>> variables. These are declared inside braces in the class extension 
>>> interface."
>>> 
>>> So, I don't know how you see that it goes in the @implementation block 
>>> since the code I pasted and the line above it say it goes in the 
>>> @interface.
>>> 
>>> Page 73 of 
>>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
>>> 
>>> On Jun 3, 2015, at 10:22 AM, Mark Wright wrote:
>>> 
 That’s a ‘Class Extension’.  Furthermore, it’s under the title "Class 
 Extensions Extend the Internal Implementation”.  It also mentions that 
 it goes in the @implementation block…
 
 
 
 
> On 03 Jun 2015, at 15:11, Alex Zavatone  wrote:
> 
> Apple's Programming with Objective-C reference document © 2014
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
> 
> 
> Page 73
> 
> @interface XYZPerson () { 
> id _someCustomInstanceVariable;
> } 
> ...
> @end
> 
> Uhh.
> 
> Doesn't this violate Clang's own mention that "declaration of 
> instance variables in the inter

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Bernard Desgraupes]

My question was unclear. I was asking about _where_ they should be declared. I 
guess they remain in the @interface.


Le 3 juin 2015 à 18:11, Mark+Vron  a écrit :

>> On 03 Jun 2015, at 16:27, Bernard Desgraupes  wrote:
>> 
>> 
>> What about the @property declarations in the new scheme ?
>> 
> 
> I’m not sure what you’re asking, @properties are a big part of the 'new way'… 
> 
> This is not about properties though, just about the notion of moving ivars 
> out of the class @interface and (if still needed) into the @implementation or 
> class extension.  There’s a clang warning that can be enabled to help you if 
> desired: -Wobjc-interface-ivars
> 
> 
> 
>> 
>> Le 3 juin 2015 à 17:15, Mark Wright  a écrit :
>> 
>>> Sorry, yes, I misread the initial paragraph that mentions the 
>>> @implementation block.  I actually meant implementation *file* since that’s 
>>> typically where the class extension @interface is declared (it extends the 
>>> class internally).
>>> 
>>> However, as you’ve surmised, all this talk of clang warnings regarding this 
>>> is directly related to the primary *class interface* which is typically 
>>> declared in the header file.  This is the class interface:
>>> 
>>> @interface SubClass : ParentClass
>>> ….
>>> @end
>>> 
>>> The idea is to end the old ways of declaring ivars in the header and move 
>>> them into the implementation where they belong (they’re private to the 
>>> class).
>>> 
>>> 
>>> 
>>> 
 On 03 Jun 2015, at 16:02, Alex Zavatone  wrote:
 
 
 On Jun 3, 2015, at 10:41 AM, David Duncan wrote:
 
> There are 3 ways to add ivars to a class. The traditional way:
> 
> @interface Foo {
>   id _bar;
> }
> 
> And 2 new ways:
> 
> @interface Foo() { // Class extension, note the ()
>   id _baz;
> }
 
 Ahhh.  Completely missed that.  Haven't seen it explained that clearly 
 in a morning of surfing.
 
 So, running a quick test using the clang pragma for 
 -Wobjc-interface-ivars, in both the .h and .m files of a class this 
 clarifies the Apple and Clang documentation quite a bit.
 
 In the 3 cases you outlined for declaring iVars, Clang ONLY warns about 
 declaring the ivars within the @interface parens of @interface which is 
 generally within the header file.
 
 Both other cases (the two new ways of class extension, @interface stuff() 
 {} and @implementation stuff {} ) do not upset Clang at all.
 
 So, generally, the rule comes down to "don't declare ivars within the 
 @interface that is probably within your .h file but if you need to (you 
 should use properties instead), you can within the class extension and 
 @implementation."
 
 Does this sound like a proper explanation?
 
 Thanks much, David.
 
 
> @implementation Foo { // Implementation block.
>   id _faz;
> }
> 
 
 
>> On Jun 3, 2015, at 7:32 AM, Alex Zavatone  wrote:
>> 
>> Maybe I should have included the text above it.
>> 
>> "It's also possible to use a class extension to add custom instance 
>> variables. These are declared inside braces in the class extension 
>> interface."
>> 
>> So, I don't know how you see that it goes in the @implementation block 
>> since the code I pasted and the line above it say it goes in the 
>> @interface.
>> 
>> Page 73 of 
>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
>> 
>> On Jun 3, 2015, at 10:22 AM, Mark Wright wrote:
>> 
>>> That’s a ‘Class Extension’.  Furthermore, it’s under the title "Class 
>>> Extensions Extend the Internal Implementation”.  It also mentions that 
>>> it goes in the @implementation block…
>>> 
>>> 
>>> 
>>> 
 On 03 Jun 2015, at 15:11, Alex Zavatone  wrote:
 
 Apple's Programming with Objective-C reference document © 2014
 
 https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
 
 
 Page 73
 
 @interface XYZPerson () { 
 id _someCustomInstanceVariable;
 } 
 ...
 @end
 
 Uhh.
 
 Doesn't this violate Clang's own mention that "declaration of instance 
 variables in the interface is deprecated" in Apple's own 
 recommendations and documentation?
 ___
 
 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/blue.buconero%40virgin.

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Mark Wright]

> On 03 Jun 2015, at 16:27, Bernard Desgraupes  wrote:
> 
> 
> What about the @property declarations in the new scheme ?
> 
> 

I’m not sure what you’re asking, @properties are a big part of the 'new way'… 

This is not about properties though, just about the notion of moving ivars out 
of the class @interface and (if still needed) into the @implementation or class 
extension.  There’s a clang warning that can be enabled to help you if desired: 
-Wobjc-interface-ivars



> 
> Le 3 juin 2015 à 17:15, Mark Wright  a écrit :
> 
>> Sorry, yes, I misread the initial paragraph that mentions the 
>> @implementation block.  I actually meant implementation *file* since that’s 
>> typically where the class extension @interface is declared (it extends the 
>> class internally).
>> 
>> However, as you’ve surmised, all this talk of clang warnings regarding this 
>> is directly related to the primary *class interface* which is typically 
>> declared in the header file.  This is the class interface:
>> 
>> @interface SubClass : ParentClass
>> ….
>> @end
>> 
>> The idea is to end the old ways of declaring ivars in the header and move 
>> them into the implementation where they belong (they’re private to the 
>> class).
>> 
>> 
>> 
>> 
>>> On 03 Jun 2015, at 16:02, Alex Zavatone  wrote:
>>> 
>>> 
>>> On Jun 3, 2015, at 10:41 AM, David Duncan wrote:
>>> 
 There are 3 ways to add ivars to a class. The traditional way:
 
 @interface Foo {
id _bar;
 }
 
 And 2 new ways:
 
 @interface Foo() { // Class extension, note the ()
id _baz;
 }
>>> 
>>> Ahhh.  Completely missed that.  Haven't seen it explained that clearly 
>>> in a morning of surfing.
>>> 
>>> So, running a quick test using the clang pragma for -Wobjc-interface-ivars, 
>>> in both the .h and .m files of a class this clarifies the Apple and Clang 
>>> documentation quite a bit.
>>> 
>>> In the 3 cases you outlined for declaring iVars, Clang ONLY warns about 
>>> declaring the ivars within the @interface parens of @interface which is 
>>> generally within the header file.
>>> 
>>> Both other cases (the two new ways of class extension, @interface stuff() 
>>> {} and @implementation stuff {} ) do not upset Clang at all.
>>> 
>>> So, generally, the rule comes down to "don't declare ivars within the 
>>> @interface that is probably within your .h file but if you need to (you 
>>> should use properties instead), you can within the class extension and 
>>> @implementation."
>>> 
>>> Does this sound like a proper explanation?
>>> 
>>> Thanks much, David.
>>> 
>>> 
 @implementation Foo { // Implementation block.
id _faz;
 }
 
>>> 
>>> 
> On Jun 3, 2015, at 7:32 AM, Alex Zavatone  wrote:
> 
> Maybe I should have included the text above it.
> 
> "It's also possible to use a class extension to add custom instance 
> variables. These are declared inside braces in the class extension 
> interface."
> 
> So, I don't know how you see that it goes in the @implementation block 
> since the code I pasted and the line above it say it goes in the 
> @interface.
> 
> Page 73 of 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
> 
> On Jun 3, 2015, at 10:22 AM, Mark Wright wrote:
> 
>> That’s a ‘Class Extension’.  Furthermore, it’s under the title "Class 
>> Extensions Extend the Internal Implementation”.  It also mentions that 
>> it goes in the @implementation block…
>> 
>> 
>> 
>> 
>>> On 03 Jun 2015, at 15:11, Alex Zavatone  wrote:
>>> 
>>> Apple's Programming with Objective-C reference document © 2014
>>> 
>>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
>>> 
>>> 
>>> Page 73
>>> 
>>> @interface XYZPerson () { 
>>> id _someCustomInstanceVariable;
>>> } 
>>> ...
>>> @end
>>> 
>>> Uhh.
>>> 
>>> Doesn't this violate Clang's own mention that "declaration of instance 
>>> variables in the interface is deprecated" in Apple's own 
>>> recommendations and documentation?
>>> ___
>>> 
>>> 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/blue.buconero%40virgin.net
>>> 
>>> This email sent to blue.bucon...@virgin.net
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderator

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[David Duncan]

> On Jun 3, 2015, at 8:27 AM, Bernard Desgraupes  wrote:
> 
> 
> What about the @property declarations in the new scheme ?

You can add @property declarations in any @interface block. Properties added in 
a class extension will be automatically synthesized. Properties added via a 
protocol (declared either on the main interface or on a class extension) are 
not auto-synthesized. Properties “added” via a category are also not auto 
synthesized for the same reasons as to why you cannot add ivars in a category.

> 
> 
> 
> Le 3 juin 2015 à 17:15, Mark Wright  a écrit :
> 
>> Sorry, yes, I misread the initial paragraph that mentions the 
>> @implementation block.  I actually meant implementation *file* since that’s 
>> typically where the class extension @interface is declared (it extends the 
>> class internally).
>> 
>> However, as you’ve surmised, all this talk of clang warnings regarding this 
>> is directly related to the primary *class interface* which is typically 
>> declared in the header file.  This is the class interface:
>> 
>> @interface SubClass : ParentClass
>> ….
>> @end
>> 
>> The idea is to end the old ways of declaring ivars in the header and move 
>> them into the implementation where they belong (they’re private to the 
>> class).
>> 
>> 
>> 
>> 
>>> On 03 Jun 2015, at 16:02, Alex Zavatone  wrote:
>>> 
>>> 
>>> On Jun 3, 2015, at 10:41 AM, David Duncan wrote:
>>> 
 There are 3 ways to add ivars to a class. The traditional way:
 
 @interface Foo {
id _bar;
 }
 
 And 2 new ways:
 
 @interface Foo() { // Class extension, note the ()
id _baz;
 }
>>> 
>>> Ahhh.  Completely missed that.  Haven't seen it explained that clearly 
>>> in a morning of surfing.
>>> 
>>> So, running a quick test using the clang pragma for -Wobjc-interface-ivars, 
>>> in both the .h and .m files of a class this clarifies the Apple and Clang 
>>> documentation quite a bit.
>>> 
>>> In the 3 cases you outlined for declaring iVars, Clang ONLY warns about 
>>> declaring the ivars within the @interface parens of @interface which is 
>>> generally within the header file.
>>> 
>>> Both other cases (the two new ways of class extension, @interface stuff() 
>>> {} and @implementation stuff {} ) do not upset Clang at all.
>>> 
>>> So, generally, the rule comes down to "don't declare ivars within the 
>>> @interface that is probably within your .h file but if you need to (you 
>>> should use properties instead), you can within the class extension and 
>>> @implementation."
>>> 
>>> Does this sound like a proper explanation?
>>> 
>>> Thanks much, David.
>>> 
>>> 
 @implementation Foo { // Implementation block.
id _faz;
 }
 
>>> 
>>> 
> On Jun 3, 2015, at 7:32 AM, Alex Zavatone  wrote:
> 
> Maybe I should have included the text above it.
> 
> "It's also possible to use a class extension to add custom instance 
> variables. These are declared inside braces in the class extension 
> interface."
> 
> So, I don't know how you see that it goes in the @implementation block 
> since the code I pasted and the line above it say it goes in the 
> @interface.
> 
> Page 73 of 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
> 
> On Jun 3, 2015, at 10:22 AM, Mark Wright wrote:
> 
>> That’s a ‘Class Extension’.  Furthermore, it’s under the title "Class 
>> Extensions Extend the Internal Implementation”.  It also mentions that 
>> it goes in the @implementation block…
>> 
>> 
>> 
>> 
>>> On 03 Jun 2015, at 15:11, Alex Zavatone  wrote:
>>> 
>>> Apple's Programming with Objective-C reference document © 2014
>>> 
>>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
>>> 
>>> 
>>> Page 73
>>> 
>>> @interface XYZPerson () { 
>>> id _someCustomInstanceVariable;
>>> } 
>>> ...
>>> @end
>>> 
>>> Uhh.
>>> 
>>> Doesn't this violate Clang's own mention that "declaration of instance 
>>> variables in the interface is deprecated" in Apple's own 
>>> recommendations and documentation?
>>> ___
>>> 
>>> 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/blue.buconero%40virgin.net
>>> 
>>> This email sent to blue.bucon...@virgin.net
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comm

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Alex Zavatone]

On Jun 3, 2015, at 11:27 AM, Bernard Desgraupes wrote:

> 
> What about the @property declarations in the new scheme ?
> 

Well, from what I've read, Apple wants you to use @properties over declaring 
ivars.  But… I don't know.

With auto-synthesis, you get ivars for free.

One point I haven't looked at is, "if @properties are declared within the 
@implementation or the class extension, are they private?  And if so, shouldn't 
they be preceded with an underscore and in that case, what does that make the 
ivar look like"?

How are we to name private properties in modern Objective-C even though 
properties were/are inherently public (as I understand it)

Currently, I've been referring to these documents from Apple:
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
https://developer.apple.com/library/mac/releasenotes/ObjectiveC/ModernizationObjC/ModernizationObjC.pdf
And the feedback from this list.

Bernard, if you want to continue my line of clarification on this topic, I'm 
sure it would help out more than just you and me.  

I'm preparing proper practice docs and sample projects to show my team how to 
not write iOS code like it's 2010 and am starting with the areas where they are 
most unclear.

Also, if you'd like my sample file that shows the Clang instance variable 
warning, I'd be glad to share it.

Cheers,

Alex Zavatone


> 
> 
> Le 3 juin 2015 à 17:15, Mark Wright  a écrit :
> 
>> Sorry, yes, I misread the initial paragraph that mentions the 
>> @implementation block.  I actually meant implementation *file* since that’s 
>> typically where the class extension @interface is declared (it extends the 
>> class internally).
>> 
>> However, as you’ve surmised, all this talk of clang warnings regarding this 
>> is directly related to the primary *class interface* which is typically 
>> declared in the header file.  This is the class interface:
>> 
>> @interface SubClass : ParentClass
>> ….
>> @end
>> 
>> The idea is to end the old ways of declaring ivars in the header and move 
>> them into the implementation where they belong (they’re private to the 
>> class).
>> 
>> 
>> 
>> 
>>> On 03 Jun 2015, at 16:02, Alex Zavatone  wrote:
>>> 
>>> 
>>> On Jun 3, 2015, at 10:41 AM, David Duncan wrote:
>>> 
 There are 3 ways to add ivars to a class. The traditional way:
 
 @interface Foo {
id _bar;
 }
 
 And 2 new ways:
 
 @interface Foo() { // Class extension, note the ()
id _baz;
 }
>>> 
>>> Ahhh.  Completely missed that.  Haven't seen it explained that clearly 
>>> in a morning of surfing.
>>> 
>>> So, running a quick test using the clang pragma for -Wobjc-interface-ivars, 
>>> in both the .h and .m files of a class this clarifies the Apple and Clang 
>>> documentation quite a bit.
>>> 
>>> In the 3 cases you outlined for declaring iVars, Clang ONLY warns about 
>>> declaring the ivars within the @interface parens of @interface which is 
>>> generally within the header file.
>>> 
>>> Both other cases (the two new ways of class extension, @interface stuff() 
>>> {} and @implementation stuff {} ) do not upset Clang at all.
>>> 
>>> So, generally, the rule comes down to "don't declare ivars within the 
>>> @interface that is probably within your .h file but if you need to (you 
>>> should use properties instead), you can within the class extension and 
>>> @implementation."
>>> 
>>> Does this sound like a proper explanation?
>>> 
>>> Thanks much, David.
>>> 
>>> 
 @implementation Foo { // Implementation block.
id _faz;
 }
 
>>> 
>>> 
> On Jun 3, 2015, at 7:32 AM, Alex Zavatone  wrote:
> 
> Maybe I should have included the text above it.
> 
> "It's also possible to use a class extension to add custom instance 
> variables. These are declared inside braces in the class extension 
> interface."
> 
> So, I don't know how you see that it goes in the @implementation block 
> since the code I pasted and the line above it say it goes in the 
> @interface.
> 
> Page 73 of 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
> 
> On Jun 3, 2015, at 10:22 AM, Mark Wright wrote:
> 
>> That’s a ‘Class Extension’.  Furthermore, it’s under the title "Class 
>> Extensions Extend the Internal Implementation”.  It also mentions that 
>> it goes in the @implementation block…
>> 
>> 
>> 
>> 
>>> On 03 Jun 2015, at 15:11, Alex Zavatone  wrote:
>>> 
>>> Apple's Programming with Objective-C reference document © 2014
>>> 
>>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
>>> 
>>> 
>>> Page 73
>>> 
>>> @interface XYZPerson () { 
>>> id _someCustomInstanceVariable;
>>> } 
>>> ...
>>> @

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Alex Zavatone]

On Jun 3, 2015, at 11:15 AM, Mark Wright wrote:

> Sorry, yes, I misread the initial paragraph that mentions the @implementation 
> block.  I actually meant implementation *file* since that’s typically where 
> the class extension @interface is declared (it extends the class internally).
> 
> However, as you’ve surmised, all this talk of clang warnings regarding this 
> is directly related to the primary *class interface* which is typically 
> declared in the header file.  This is the class interface:
> 
> @interface SubClass : ParentClass
> ….
> @end
> 
> The idea is to end the old ways of declaring ivars in the header and move 
> them into the implementation where they belong (they’re private to the class).

This has been absolutely great.

By being able to spell out EXACTLY how and why to implement ivars (if they 
must), I've been able to create a simple project for my team that shows where 
they are supported, where they aren't supported, what the difference is and 
have comments that state "simply use properties instead and access the 
autocreated _ivar from autosynthesized @properties".

It would be nice to have them NOT add to the 218+ warnings we already have 
because of our ivar mess and now I have the sample for them to learn from.

Super awesome.  

Thanks, David and Mark.

- Alex Zavatone



> 
> 
> 
>> On 03 Jun 2015, at 16:02, Alex Zavatone  wrote:
>> 
>> 
>> On Jun 3, 2015, at 10:41 AM, David Duncan wrote:
>> 
>>> There are 3 ways to add ivars to a class. The traditional way:
>>> 
>>> @interface Foo {
>>> id _bar;
>>> }
>>> 
>>> And 2 new ways:
>>> 
>>> @interface Foo() { // Class extension, note the ()
>>> id _baz;
>>> }
>> 
>> Ahhh.  Completely missed that.  Haven't seen it explained that clearly 
>> in a morning of surfing.
>> 
>> So, running a quick test using the clang pragma for -Wobjc-interface-ivars, 
>> in both the .h and .m files of a class this clarifies the Apple and Clang 
>> documentation quite a bit.
>> 
>> In the 3 cases you outlined for declaring iVars, Clang ONLY warns about 
>> declaring the ivars within the @interface parens of @interface which is 
>> generally within the header file.
>> 
>> Both other cases (the two new ways of class extension, @interface stuff() {} 
>> and @implementation stuff {} ) do not upset Clang at all.
>> 
>> So, generally, the rule comes down to "don't declare ivars within the 
>> @interface that is probably within your .h file but if you need to (you 
>> should use properties instead), you can within the class extension and 
>> @implementation."
>> 
>> Does this sound like a proper explanation?
>> 
>> Thanks much, David.
>> 
>> 
>>> @implementation Foo { // Implementation block.
>>> id _faz;
>>> }
>>> 
>> 
>> 
 On Jun 3, 2015, at 7:32 AM, Alex Zavatone  wrote:
 
 Maybe I should have included the text above it.
 
 "It's also possible to use a class extension to add custom instance 
 variables. These are declared inside braces in the class extension 
 interface."
 
 So, I don't know how you see that it goes in the @implementation block 
 since the code I pasted and the line above it say it goes in the 
 @interface.
 
 Page 73 of 
 https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
 
 On Jun 3, 2015, at 10:22 AM, Mark Wright wrote:
 
> That’s a ‘Class Extension’.  Furthermore, it’s under the title "Class 
> Extensions Extend the Internal Implementation”.  It also mentions that it 
> goes in the @implementation block…
> 
> 
> 
> 
>> On 03 Jun 2015, at 15:11, Alex Zavatone  wrote:
>> 
>> Apple's Programming with Objective-C reference document © 2014
>> 
>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
>> 
>> 
>> Page 73
>> 
>> @interface XYZPerson () { 
>> id _someCustomInstanceVariable;
>> } 
>> ...
>> @end
>> 
>> Uhh.
>> 
>> Doesn't this violate Clang's own mention that "declaration of instance 
>> variables in the interface is deprecated" in Apple's own recommendations 
>> and documentation?
>> ___
>> 
>> 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/blue.buconero%40virgin.net
>> 
>> This email sent to blue.bucon...@virgin.net
> 
 
 ___
 
 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-d

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Bernard Desgraupes]

What about the @property declarations in the new scheme ?



Le 3 juin 2015 à 17:15, Mark Wright  a écrit :

> Sorry, yes, I misread the initial paragraph that mentions the @implementation 
> block.  I actually meant implementation *file* since that’s typically where 
> the class extension @interface is declared (it extends the class internally).
> 
> However, as you’ve surmised, all this talk of clang warnings regarding this 
> is directly related to the primary *class interface* which is typically 
> declared in the header file.  This is the class interface:
> 
> @interface SubClass : ParentClass
> ….
> @end
> 
> The idea is to end the old ways of declaring ivars in the header and move 
> them into the implementation where they belong (they’re private to the class).
> 
> 
> 
> 
>> On 03 Jun 2015, at 16:02, Alex Zavatone  wrote:
>> 
>> 
>> On Jun 3, 2015, at 10:41 AM, David Duncan wrote:
>> 
>>> There are 3 ways to add ivars to a class. The traditional way:
>>> 
>>> @interface Foo {
>>> id _bar;
>>> }
>>> 
>>> And 2 new ways:
>>> 
>>> @interface Foo() { // Class extension, note the ()
>>> id _baz;
>>> }
>> 
>> Ahhh.  Completely missed that.  Haven't seen it explained that clearly 
>> in a morning of surfing.
>> 
>> So, running a quick test using the clang pragma for -Wobjc-interface-ivars, 
>> in both the .h and .m files of a class this clarifies the Apple and Clang 
>> documentation quite a bit.
>> 
>> In the 3 cases you outlined for declaring iVars, Clang ONLY warns about 
>> declaring the ivars within the @interface parens of @interface which is 
>> generally within the header file.
>> 
>> Both other cases (the two new ways of class extension, @interface stuff() {} 
>> and @implementation stuff {} ) do not upset Clang at all.
>> 
>> So, generally, the rule comes down to "don't declare ivars within the 
>> @interface that is probably within your .h file but if you need to (you 
>> should use properties instead), you can within the class extension and 
>> @implementation."
>> 
>> Does this sound like a proper explanation?
>> 
>> Thanks much, David.
>> 
>> 
>>> @implementation Foo { // Implementation block.
>>> id _faz;
>>> }
>>> 
>> 
>> 
 On Jun 3, 2015, at 7:32 AM, Alex Zavatone  wrote:
 
 Maybe I should have included the text above it.
 
 "It's also possible to use a class extension to add custom instance 
 variables. These are declared inside braces in the class extension 
 interface."
 
 So, I don't know how you see that it goes in the @implementation block 
 since the code I pasted and the line above it say it goes in the 
 @interface.
 
 Page 73 of 
 https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
 
 On Jun 3, 2015, at 10:22 AM, Mark Wright wrote:
 
> That’s a ‘Class Extension’.  Furthermore, it’s under the title "Class 
> Extensions Extend the Internal Implementation”.  It also mentions that it 
> goes in the @implementation block…
> 
> 
> 
> 
>> On 03 Jun 2015, at 15:11, Alex Zavatone  wrote:
>> 
>> Apple's Programming with Objective-C reference document © 2014
>> 
>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
>> 
>> 
>> Page 73
>> 
>> @interface XYZPerson () { 
>> id _someCustomInstanceVariable;
>> } 
>> ...
>> @end
>> 
>> Uhh.
>> 
>> Doesn't this violate Clang's own mention that "declaration of instance 
>> variables in the interface is deprecated" in Apple's own recommendations 
>> and documentation?
>> ___
>> 
>> 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/blue.buconero%40virgin.net
>> 
>> This email sent to blue.bucon...@virgin.net
> 
 
 ___
 
 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/david.duncan%40apple.com
 
 This email sent to david.dun...@apple.com
>>> 
>>> --
>>> David Duncan
>>> 
>> 
> 
> 
> ___
> 
> 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 Subsc

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Mark Wright]

Sorry, yes, I misread the initial paragraph that mentions the @implementation 
block.  I actually meant implementation *file* since that’s typically where the 
class extension @interface is declared (it extends the class internally).

However, as you’ve surmised, all this talk of clang warnings regarding this is 
directly related to the primary *class interface* which is typically declared 
in the header file.  This is the class interface:

@interface SubClass : ParentClass
….
@end

The idea is to end the old ways of declaring ivars in the header and move them 
into the implementation where they belong (they’re private to the class).




> On 03 Jun 2015, at 16:02, Alex Zavatone  wrote:
> 
> 
> On Jun 3, 2015, at 10:41 AM, David Duncan wrote:
> 
>> There are 3 ways to add ivars to a class. The traditional way:
>> 
>> @interface Foo {
>>  id _bar;
>> }
>> 
>> And 2 new ways:
>> 
>> @interface Foo() { // Class extension, note the ()
>>  id _baz;
>> }
> 
> Ahhh.  Completely missed that.  Haven't seen it explained that clearly in 
> a morning of surfing.
> 
> So, running a quick test using the clang pragma for -Wobjc-interface-ivars, 
> in both the .h and .m files of a class this clarifies the Apple and Clang 
> documentation quite a bit.
> 
> In the 3 cases you outlined for declaring iVars, Clang ONLY warns about 
> declaring the ivars within the @interface parens of @interface which is 
> generally within the header file.
> 
> Both other cases (the two new ways of class extension, @interface stuff() {} 
> and @implementation stuff {} ) do not upset Clang at all.
> 
> So, generally, the rule comes down to "don't declare ivars within the 
> @interface that is probably within your .h file but if you need to (you 
> should use properties instead), you can within the class extension and 
> @implementation."
> 
> Does this sound like a proper explanation?
> 
> Thanks much, David.
> 
> 
>> @implementation Foo { // Implementation block.
>>  id _faz;
>> }
>> 
> 
> 
>>> On Jun 3, 2015, at 7:32 AM, Alex Zavatone  wrote:
>>> 
>>> Maybe I should have included the text above it.
>>> 
>>> "It's also possible to use a class extension to add custom instance 
>>> variables. These are declared inside braces in the class extension 
>>> interface."
>>> 
>>> So, I don't know how you see that it goes in the @implementation block 
>>> since the code I pasted and the line above it say it goes in the @interface.
>>> 
>>> Page 73 of 
>>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
>>> 
>>> On Jun 3, 2015, at 10:22 AM, Mark Wright wrote:
>>> 
 That’s a ‘Class Extension’.  Furthermore, it’s under the title "Class 
 Extensions Extend the Internal Implementation”.  It also mentions that it 
 goes in the @implementation block…
 
 
 
 
> On 03 Jun 2015, at 15:11, Alex Zavatone  wrote:
> 
> Apple's Programming with Objective-C reference document © 2014
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
> 
> 
> Page 73
> 
> @interface XYZPerson () { 
> id _someCustomInstanceVariable;
> } 
> ...
> @end
> 
> Uhh.
> 
> Doesn't this violate Clang's own mention that "declaration of instance 
> variables in the interface is deprecated" in Apple's own recommendations 
> and documentation?
> ___
> 
> 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/blue.buconero%40virgin.net
> 
> This email sent to blue.bucon...@virgin.net
 
>>> 
>>> ___
>>> 
>>> 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/david.duncan%40apple.com
>>> 
>>> This email sent to david.dun...@apple.com
>> 
>> --
>> David Duncan
>> 
> 


___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Alex Zavatone]

On Jun 3, 2015, at 10:41 AM, David Duncan wrote:

> There are 3 ways to add ivars to a class. The traditional way:
> 
> @interface Foo {
>   id _bar;
> }
> 
> And 2 new ways:
> 
> @interface Foo() { // Class extension, note the ()
>   id _baz;
> }

Ahhh.  Completely missed that.  Haven't seen it explained that clearly in a 
morning of surfing.

So, running a quick test using the clang pragma for -Wobjc-interface-ivars, in 
both the .h and .m files of a class this clarifies the Apple and Clang 
documentation quite a bit.

In the 3 cases you outlined for declaring iVars, Clang ONLY warns about 
declaring the ivars within the @interface parens of @interface which is 
generally within the header file.

Both other cases (the two new ways of class extension, @interface stuff() {} 
and @implementation stuff {} ) do not upset Clang at all.

So, generally, the rule comes down to "don't declare ivars within the 
@interface that is probably within your .h file but if you need to (you should 
use properties instead), you can within the class extension and 
@implementation."

Does this sound like a proper explanation?

Thanks much, David.


> @implementation Foo { // Implementation block.
>   id _faz;
> }
> 


>> On Jun 3, 2015, at 7:32 AM, Alex Zavatone  wrote:
>> 
>> Maybe I should have included the text above it.
>> 
>> "It's also possible to use a class extension to add custom instance 
>> variables. These are declared inside braces in the class extension 
>> interface."
>> 
>> So, I don't know how you see that it goes in the @implementation block since 
>> the code I pasted and the line above it say it goes in the @interface.
>> 
>> Page 73 of 
>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
>> 
>> On Jun 3, 2015, at 10:22 AM, Mark Wright wrote:
>> 
>>> That’s a ‘Class Extension’.  Furthermore, it’s under the title "Class 
>>> Extensions Extend the Internal Implementation”.  It also mentions that it 
>>> goes in the @implementation block…
>>> 
>>> 
>>> 
>>> 
 On 03 Jun 2015, at 15:11, Alex Zavatone  wrote:
 
 Apple's Programming with Objective-C reference document © 2014
 
 https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
 
 
 Page 73
 
 @interface XYZPerson () { 
 id _someCustomInstanceVariable;
 } 
 ...
 @end
 
 Uhh.
 
 Doesn't this violate Clang's own mention that "declaration of instance 
 variables in the interface is deprecated" in Apple's own recommendations 
 and documentation?
 ___
 
 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/blue.buconero%40virgin.net
 
 This email sent to blue.bucon...@virgin.net
>>> 
>> 
>> ___
>> 
>> 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/david.duncan%40apple.com
>> 
>> This email sent to david.dun...@apple.com
> 
> --
> David Duncan
> 


___

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

Re: How to enable local storage in WebView using Swift

[Roland King]

> On 3 Jun 2015, at 22:23, Juanjo Conti  wrote:
> 
> Hi, I'm using WebView and I'd like to enable HTML5 local storage.
> 
> I've read some questions on Stack Overflow where the suggestion is to do:
> 
>WebPreferences *prefs = [webView preferences];
>[prefs _setLocalStorageDatabasePath:@"~/Library/Application
> Support/MyApp"];
>[prefs setLocalStorageEnabled:YES];
> 
> but if I try something similar in Swift:
> 
>webView.preferences._setLocalStorageDatabasePath(LocalStoragePath)
>webView.preferences.localStorage = true
> I get a "WebPreferences does not have a member named ..." error.
> 
> How can I do it?
> 
> Thanks in advance,

_setLocalStorageDatabasePath just has to be a private method and I don’t see 
any documentation on localStorageEnabled or anything similar so I’m guessing 
that’s a private method too. 

Swift doesn’t let you call private methods, so you can’t do it. Well you could 
write a little shim in objective c and call that from Swift, I guess even that 
workaround will fail one day. 

A quick google seems to indicate that not only are those methods private, they 
don’t exist in recent OS, so you need to find another way. 
___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[David Duncan]

There are 3 ways to add ivars to a class. The traditional way:

@interface Foo {
id _bar;
}

And 2 new ways:

@interface Foo() { // Class extension, note the ()
id _baz;
}

@implementation Foo { // Implementation block.
id _faz;
}

> On Jun 3, 2015, at 7:32 AM, Alex Zavatone  wrote:
> 
> Maybe I should have included the text above it.
> 
>  "It's also possible to use a class extension to add custom instance 
> variables. These are declared inside braces in the class extension interface."
> 
> So, I don't know how you see that it goes in the @implementation block since 
> the code I pasted and the line above it say it goes in the @interface.
> 
> Page 73 of 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
> 
> On Jun 3, 2015, at 10:22 AM, Mark Wright wrote:
> 
>> That’s a ‘Class Extension’.  Furthermore, it’s under the title "Class 
>> Extensions Extend the Internal Implementation”.  It also mentions that it 
>> goes in the @implementation block…
>> 
>> 
>> 
>> 
>>> On 03 Jun 2015, at 15:11, Alex Zavatone  wrote:
>>> 
>>> Apple's Programming with Objective-C reference document © 2014
>>> 
>>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
>>> 
>>> 
>>> Page 73
>>> 
>>> @interface XYZPerson () { 
>>>  id _someCustomInstanceVariable;
>>> } 
>>> ...
>>> @end
>>> 
>>> Uhh.
>>> 
>>> Doesn't this violate Clang's own mention that "declaration of instance 
>>> variables in the interface is deprecated" in Apple's own recommendations 
>>> and documentation?
>>> ___
>>> 
>>> 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/blue.buconero%40virgin.net
>>> 
>>> This email sent to blue.bucon...@virgin.net
>> 
> 
> ___
> 
> 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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan


___

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

Re: How to enable local storage in WebView using Swift

[Juanjo Conti]

BTW; I get the error in both lines.

On Wed, Jun 3, 2015 at 11:35 AM, Juanjo Conti 
wrote:

> Same error with both names.
>
> On Wed, Jun 3, 2015 at 11:31 AM, Scott Ribe 
> wrote:
>
>> On Jun 3, 2015, at 8:23 AM, Juanjo Conti 
>> wrote:
>> >
>> > Hi, I'm using WebView and I'd like to enable HTML5 local storage.
>> >
>> > I've read some questions on Stack Overflow where the suggestion is to
>> do:
>> >
>> > WebPreferences *prefs = [webView preferences];
>> > [prefs _setLocalStorageDatabasePath:@"~/Library/Application
>> Support/MyApp"];
>> > [prefs setLocalStorageEnabled:YES];
>> >
>> > but if I try something similar in Swift:
>> >
>> > webView.preferences._setLocalStorageDatabasePath(LocalStoragePath)
>> > webView.preferences.localStorage = true
>> >
>> > I get a "WebPreferences does not have a member named ..." error.
>> >
>> > How can I do it?
>> >
>> > Thanks in advance,
>>
>> I don't know Swift, nor much about WebViews, but I'd guess it's because
>> you got the member name wrong. Try localStorageEnabled.
>>
>> --
>> Scott Ribe
>> scott_r...@elevated-dev.com
>> http://www.elevated-dev.com/
>> https://www.linkedin.com/in/scottribe/
>> (303) 722-0567 voice
>>
>>
>>
>>
>>
>>
>
>
> --
>
> Juanjo Conti http://goog_2023646312>@carouselapps.com
> >
>
> Software Engineer - Carousel Apps 
>
>


-- 

Juanjo Conti http://goog_2023646312>@carouselapps.com
>

Software Engineer - Carousel Apps 

-- 
Carousel Apps Limited, registered in England & Wales with registered number 
7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket 
Street, London SE1 3HN. Any communication sent by or on behalf of Carousel 
App Ltd or any of its subsidiary, holding or affiliated companies or 
entities (together "Watu") is confidential and may be privileged or 
otherwise protected. If you receive it in error please inform us and then 
delete it from your system. You should not copy it or disclose its contents 
to anyone. Messages sent to and from Watu may be monitored to ensure 
compliance with our internal policies and to protect our business. Emails 
are not secure and cannot be guaranteed to be error free. Anyone who 
communicates with us by email is taken to accept these risks.
___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Alex Zavatone]

Maybe I should have included the text above it.

  "It's also possible to use a class extension to add custom instance 
variables. These are declared inside braces in the class extension interface."

So, I don't know how you see that it goes in the @implementation block since 
the code I pasted and the line above it say it goes in the @interface.

Page 73 of 
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf

On Jun 3, 2015, at 10:22 AM, Mark Wright wrote:

> That’s a ‘Class Extension’.  Furthermore, it’s under the title "Class 
> Extensions Extend the Internal Implementation”.  It also mentions that it 
> goes in the @implementation block…
> 
> 
> 
> 
>> On 03 Jun 2015, at 15:11, Alex Zavatone  wrote:
>> 
>> Apple's Programming with Objective-C reference document © 2014
>> 
>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
>> 
>> 
>> Page 73
>> 
>> @interface XYZPerson () { 
>>   id _someCustomInstanceVariable;
>> } 
>> ...
>> @end
>> 
>> Uhh.
>> 
>> Doesn't this violate Clang's own mention that "declaration of instance 
>> variables in the interface is deprecated" in Apple's own recommendations and 
>> documentation?
>> ___
>> 
>> 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/blue.buconero%40virgin.net
>> 
>> This email sent to blue.bucon...@virgin.net
> 

___

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

Re: How to enable local storage in WebView using Swift

[Juanjo Conti]

Same error with both names.

On Wed, Jun 3, 2015 at 11:31 AM, Scott Ribe 
wrote:

> On Jun 3, 2015, at 8:23 AM, Juanjo Conti  wrote:
> >
> > Hi, I'm using WebView and I'd like to enable HTML5 local storage.
> >
> > I've read some questions on Stack Overflow where the suggestion is to do:
> >
> > WebPreferences *prefs = [webView preferences];
> > [prefs _setLocalStorageDatabasePath:@"~/Library/Application
> Support/MyApp"];
> > [prefs setLocalStorageEnabled:YES];
> >
> > but if I try something similar in Swift:
> >
> > webView.preferences._setLocalStorageDatabasePath(LocalStoragePath)
> > webView.preferences.localStorage = true
> >
> > I get a "WebPreferences does not have a member named ..." error.
> >
> > How can I do it?
> >
> > Thanks in advance,
>
> I don't know Swift, nor much about WebViews, but I'd guess it's because
> you got the member name wrong. Try localStorageEnabled.
>
> --
> Scott Ribe
> scott_r...@elevated-dev.com
> http://www.elevated-dev.com/
> https://www.linkedin.com/in/scottribe/
> (303) 722-0567 voice
>
>
>
>
>
>


-- 

Juanjo Conti http://goog_2023646312>@carouselapps.com
>

Software Engineer - Carousel Apps 

-- 
Carousel Apps Limited, registered in England & Wales with registered number 
7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket 
Street, London SE1 3HN. Any communication sent by or on behalf of Carousel 
App Ltd or any of its subsidiary, holding or affiliated companies or 
entities (together "Watu") is confidential and may be privileged or 
otherwise protected. If you receive it in error please inform us and then 
delete it from your system. You should not copy it or disclose its contents 
to anyone. Messages sent to and from Watu may be monitored to ensure 
compliance with our internal policies and to protect our business. Emails 
are not secure and cannot be guaranteed to be error free. Anyone who 
communicates with us by email is taken to accept these risks.
___

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

Re: How to enable local storage in WebView using Swift

[Scott Ribe]

On Jun 3, 2015, at 8:23 AM, Juanjo Conti  wrote:
> 
> Hi, I'm using WebView and I'd like to enable HTML5 local storage.
> 
> I've read some questions on Stack Overflow where the suggestion is to do:
> 
> WebPreferences *prefs = [webView preferences];
> [prefs _setLocalStorageDatabasePath:@"~/Library/Application 
> Support/MyApp"];
> [prefs setLocalStorageEnabled:YES];
> 
> but if I try something similar in Swift:
> 
> webView.preferences._setLocalStorageDatabasePath(LocalStoragePath)
> webView.preferences.localStorage = true
> 
> I get a "WebPreferences does not have a member named ..." error.
> 
> How can I do it?
> 
> Thanks in advance,

I don't know Swift, nor much about WebViews, but I'd guess it's because you got 
the member name wrong. Try localStorageEnabled.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice






___

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

How to enable local storage in WebView using Swift

[Juanjo Conti]

Hi, I'm using WebView and I'd like to enable HTML5 local storage.

I've read some questions on Stack Overflow where the suggestion is to do:

WebPreferences *prefs = [webView preferences];
[prefs _setLocalStorageDatabasePath:@"~/Library/Application
Support/MyApp"];
[prefs setLocalStorageEnabled:YES];

but if I try something similar in Swift:

webView.preferences._setLocalStorageDatabasePath(LocalStoragePath)
webView.preferences.localStorage = true
I get a "WebPreferences does not have a member named ..." error.

How can I do it?

Thanks in advance,

-- 

Juanjo Conti http://goog_2023646312>@carouselapps.com
>

Software Engineer - Carousel Apps 

-- 
Carousel Apps Limited, registered in England & Wales with registered number 
7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket 
Street, London SE1 3HN. Any communication sent by or on behalf of Carousel 
App Ltd or any of its subsidiary, holding or affiliated companies or 
entities (together "Watu") is confidential and may be privileged or 
otherwise protected. If you receive it in error please inform us and then 
delete it from your system. You should not copy it or disclose its contents 
to anyone. Messages sent to and from Watu may be monitored to ensure 
compliance with our internal policies and to protect our business. Emails 
are not secure and cannot be guaranteed to be error free. Anyone who 
communicates with us by email is taken to accept these risks.
___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Mark Wright]

That’s a ‘Class Extension’.  Furthermore, it’s under the title "Class 
Extensions Extend the Internal Implementation”.  It also mentions that it goes 
in the @implementation block…




> On 03 Jun 2015, at 15:11, Alex Zavatone  wrote:
> 
> Apple's Programming with Objective-C reference document © 2014
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
> 
> 
> Page 73
> 
> @interface XYZPerson () { 
>id _someCustomInstanceVariable;
> } 
> ...
> @end
> 
> Uhh.
> 
> Doesn't this violate Clang's own mention that "declaration of instance 
> variables in the interface is deprecated" in Apple's own recommendations and 
> documentation?
> ___
> 
> 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/blue.buconero%40virgin.net
> 
> This email sent to blue.bucon...@virgin.net


___

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

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.

[David Duncan]

I’m fairly certain the warning is newer than the documentation.

> On Jun 3, 2015, at 7:11 AM, Alex Zavatone  wrote:
> 
> Apple's Programming with Objective-C reference document © 2014
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf
> 
> 
> Page 73
> 
> @interface XYZPerson () { 
>id _someCustomInstanceVariable;
> } 
> ...
> @end
> 
> Uhh.
> 
> Doesn't this violate Clang's own mention that "declaration of instance 
> variables in the interface is deprecated" in Apple's own recommendations and 
> documentation?
> ___
> 
> 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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan


___

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

Understanding the "declaration of instance variables in the interface is deprecated" warning.

[Alex Zavatone]

Apple's Programming with Objective-C reference document © 2014

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf


Page 73

@interface XYZPerson () { 
id _someCustomInstanceVariable;
} 
...
@end

Uhh.

Doesn't this violate Clang's own mention that "declaration of instance 
variables in the interface is deprecated" in Apple's own recommendations and 
documentation?
___

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

Re: Looking at self = [super init].

[Scott Ribe]

On Jun 3, 2015, at 6:30 AM, Alex Zavatone  wrote:
> 
> With that in mind, what should it have depended on instead?

His point was not that such dependence was bad, nor even avoidable. His point 
was that the C++ was a steaming pile ;-)

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice






___

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

Re: Looking at self = [super init].

[Alex Zavatone]

On Jun 3, 2015, at 9:02 AM, Alex Zavatone wrote:

> 
> On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote:
> 
>> On Jun 1, 2015, at 11:43 PM, Britt Durbrow 
>>  wrote:
>>> 
>> 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.  

AHA!

I couldn't find out how to add it through the Build Settings, (thanks terrible 
UI!), but If you want this in your project and your project has a .pch file, 
you can turn on the warning through a pragma and a clang diagnostic push by 
adding the code below to your .project wide header file.

/ AZ @@ 06030215 - Enable warnings on build for private interface variables 
manually declared in the @interface.
# pragma clang diagnostic push
# pragma clang diagnostic warning "-Wobjc-interface-ivars"

Thanks to Matt Thompson for his pragma article and the Clang docs.
http://nshipster.com/pragma/
http://clang.llvm.org/docs/UsersManual.html
http://fuckingclangwarnings.com/

Hope this is of use to some of you too.

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Looking at self = [super init].

[Alex Zavatone]

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

> On Jun 1, 2015, at 11:43 PM, Britt Durbrow 
>  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 >> > 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

Re: Looking at self = [super init].

[Alex Zavatone]

On Jun 2, 2015, at 9:07 PM, Michael David Crawford wrote:

> What horrified me was that they were completely unaware that their
> product was likely to drop a pickup truck on top of an assembly plant
> worker.  While the overall architecture had all manner of
> fault-tolerance engineered in, that fault-tolerance depended on
> correct C++ code.

With that in mind, what should it have depended on instead?


___

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