Re: Understanding the declaration of instance variables in the interface is deprecated warning.
On Jun 4, 2015, at 9:16 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 04 Jun 2015, at 02:36, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: On Jun 3, 2015, at 11:30 AM, Mark Wright blue.bucon...@virgin.net 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(). There’s also key-value coding, i.e. [obj valueForKey: @“accessor”] and [obj setValue: @1 forKey: @“accessor”], and the implicit occurrences thereof in e.g. XIB loading. I would classify that as an indirect way, as it’s not actually built into the language (it comes from NSObject)… and FWIW, there’s also NSInvocation, and any number of third-party invocation or KVC wrappers. ___ 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.
On 03 Jun 2015, at 20:30, Mark Wright blue.bucon...@virgin.net wrote: 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). We’re fully in agreement that ivars’ names don’t matter, while methods are important WRT avoiding the underscore. The issue is just that if you want to make a private *property* (as opposed to a private ivar), you can’t use an underscore prefix, because that would implicitly generate a getter *method* with an underscore. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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.
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.
On 03 Jun 2015, at 19:54, Alex Zavatone z...@mac.com 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: Understanding the declaration of instance variables in the interface is deprecated warning.
On Jun 3, 2015, at 11:30 AM, Mark Wright blue.bucon...@virgin.net 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: Understanding the declaration of instance variables in the interface is deprecated warning.
I’m fairly certain the warning is newer than the documentation.
On Jun 3, 2015, at 7:11 AM, Alex Zavatone z...@mac.com 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.
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: Understanding the declaration of instance variables in the interface is deprecated warning.
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 z...@mac.com 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.
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 z...@mac.com 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 z...@mac.com 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.
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 z...@mac.com 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.
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 z...@mac.com 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 z...@mac.com 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.
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 z...@mac.com 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 z...@mac.com 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 z...@mac.com 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
Re: Understanding the declaration of instance variables in the interface is deprecated warning.
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 blue.bucon...@virgin.net 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 z...@mac.com 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 z...@mac.com 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 z...@mac.com 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
Re: Understanding the declaration of instance variables in the interface is deprecated warning.
On 03 Jun 2015, at 16:27, Bernard Desgraupes bdesgrau...@orange.fr 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 blue.bucon...@virgin.net 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 z...@mac.com 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 z...@mac.com 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 z...@mac.com 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
Re: Understanding the declaration of instance variables in the interface is deprecated warning.
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 z...@mac.com 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 z...@mac.com 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 z...@mac.com 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.
What about the @property declarations in the new scheme ?
Le 3 juin 2015 à 17:15, Mark Wright blue.bucon...@virgin.net 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 z...@mac.com 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 z...@mac.com 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 z...@mac.com 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/bdesgraupes%40orange.fr
This email sent to bdesgrau...@orange.fr
___
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:
Re: Understanding the declaration of instance variables in the interface is deprecated warning.
On Jun 3, 2015, at 8:27 AM, Bernard Desgraupes bdesgrau...@orange.fr 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 blue.bucon...@virgin.net 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 z...@mac.com 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 z...@mac.com 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 z...@mac.com 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
Re: Understanding the declaration of instance variables in the interface is deprecated warning.
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 mark.v...@virgin.net a écrit :
On 03 Jun 2015, at 16:27, Bernard Desgraupes bdesgrau...@orange.fr 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 blue.bucon...@virgin.net 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 z...@mac.com 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 z...@mac.com 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 z...@mac.com 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
Re: Understanding the declaration of instance variables in the interface is deprecated warning.
On 03 Jun 2015, at 17:08, Alex Zavatone z...@mac.com 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.
On 03 Jun 2015, at 18:46, Mark Wright blue.bucon...@virgin.net wrote: On 03 Jun 2015, at 17:08, Alex Zavatone z...@mac.com 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.
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.
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 mark.v...@virgin.net a écrit :
On 03 Jun 2015, at 16:27, Bernard Desgraupes bdesgrau...@orange.fr 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 blue.bucon...@virgin.net 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 z...@mac.com 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 z...@mac.com 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 z...@mac.com 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
Re: Understanding the declaration of instance variables in the interface is deprecated warning.
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.
On Jun 3, 2015, at 1:59 PM, Uli Kusterer wrote: On 03 Jun 2015, at 19:09, Alex Zavatone z...@mac.com 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.
On 03 Jun 2015, at 18:59, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 03 Jun 2015, at 19:09, Alex Zavatone z...@mac.com 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.
On 03 Jun 2015, at 19:06, Alex Zavatone z...@mac.com 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.
On 03 Jun 2015, at 19:09, Alex Zavatone z...@mac.com 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
