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;
> }

Ahhhhhhh.  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
>>>> 
>>>> Uhhhhhh.
>>>> 
>>>> 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

Reply via email to