• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.


  • Subject: Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.
  • From: Alex Zavatone <email@hidden>
  • Date: Wed, 03 Jun 2015 12:29:52 -0400
  • Sun-java-system-smtp-warning: Lines longer than SMTP allows found and wrapped.

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 <email@hidden> a écrit :
>
>>> On 03 Jun 2015, at 16:27, Bernard Desgraupes <email@hidden> 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 <email@hidden> 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 <email@hidden> 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 <email@hidden> 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 <email@hidden> 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 (email@hidden)
>>>>>>>>>
>>>>>>>>> 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:
>>>>>>>>>
>>>>>>>>> This email sent to email@hidden
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>> Cocoa-dev mailing list (email@hidden)
>>>>>>>
>>>>>>> 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:
>>>>>>>
>>>>>>> This email sent to email@hidden
>>>>>>
>>>>>> --
>>>>>> David Duncan
>>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Cocoa-dev mailing list (email@hidden)
>>>>
>>>> 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:
>>>>
>>>> This email sent to email@hidden
>>>
>>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> 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:
>>>
>>> This email sent to email@hidden
>>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden


_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden


References: 
 >Re: Looking at self = [super init]. (From: Dave <email@hidden>)
 >Re: Looking at self = [super init]. (From: Britt Durbrow <email@hidden>)
 >Re: Looking at self = [super init]. (From: Quincey Morris <email@hidden>)
 >Re: Looking at self = [super init]. (From: Charles Srstka <email@hidden>)
 >Re: Looking at self = [super init]. (From: Michael David Crawford <email@hidden>)
 >Re: Looking at self = [super init]. (From: Britt Durbrow <email@hidden>)
 >Re: Looking at self = [super init]. (From: Charles Srstka <email@hidden>)
 >Re: Looking at self = [super init]. (From: Alex Zavatone <email@hidden>)
 >Re: Looking at self = [super init]. (From: Alex Zavatone <email@hidden>)
 >Understanding the "declaration of instance variables in the interface is deprecated" warning. (From: Alex Zavatone <email@hidden>)
 >Re: Understanding the "declaration of instance variables in the interface is deprecated" warning. (From: Mark Wright <email@hidden>)
 >Re: Understanding the "declaration of instance variables in the interface is deprecated" warning. (From: Alex Zavatone <email@hidden>)
 >Re: Understanding the "declaration of instance variables in the interface is deprecated" warning. (From: David Duncan <email@hidden>)
 >Re: Understanding the "declaration of instance variables in the interface is deprecated" warning. (From: Alex Zavatone <email@hidden>)
 >Re: Understanding the "declaration of instance variables in the interface is deprecated" warning. (From: Mark Wright <email@hidden>)
 >Re: Understanding the "declaration of instance variables in the interface is deprecated" warning. (From: Bernard Desgraupes <email@hidden>)
 >Re: Understanding the "declaration of instance variables in the interface is deprecated" warning. (From: Bernard Desgraupes <email@hidden>)

  • Prev by Date: Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.
  • Next by Date: Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.
  • Previous by thread: Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.
  • Next by thread: Re: Looking at self = [super init].
  • Index(es):
    • Date
    • Thread