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