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