> 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
