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;
>>> }
>>
>> 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/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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
