On Jun 3, 2015, at 11:27 AM, Bernard Desgraupes wrote: > > What about the @property declarations in the new scheme ? >
Well, from what I've read, Apple wants you to use @properties over declaring ivars. But… I don't know. With auto-synthesis, you get ivars for free. One point I haven't looked at is, "if @properties are declared within the @implementation or the class extension, are they private? And if so, shouldn't they be preceded with an underscore and in that case, what does that make the ivar look like"? How are we to name private properties in modern Objective-C even though properties were/are inherently public (as I understand it) Currently, I've been referring to these documents from Apple: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ProgrammingWithObjectiveC.pdf https://developer.apple.com/library/mac/releasenotes/ObjectiveC/ModernizationObjC/ModernizationObjC.pdf And the feedback from this list. Bernard, if you want to continue my line of clarification on this topic, I'm sure it would help out more than just you and me. I'm preparing proper practice docs and sample projects to show my team how to not write iOS code like it's 2010 and am starting with the areas where they are most unclear. Also, if you'd like my sample file that shows the Clang instance variable warning, I'd be glad to share it. Cheers, Alex Zavatone > > > 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/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
