Here's what I found to be great places to start from within one of Apple's docs.
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf Essential reading Page 16: Page 43: Page 73: Use Class Extensions to Hide Private Information On Jun 3, 2015, at 12:24 PM, Bernard Desgraupes wrote: > > 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/zav%40mac.com > > This email sent to z...@mac.com _______________________________________________ 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
