Re: [ANN] PropertyMaster(TM): customizable Xcode script to create, cleanup, and maintain properties-synthesize-viewDidUnload-dealloc
Re: [ANN] PropertyMaster(TM): customizable Xcode script to create, cleanup, and maintain properties-synthesize-viewDidUnload-dealloc
- Subject: Re: [ANN] PropertyMaster(TM): customizable Xcode script to create, cleanup, and maintain properties-synthesize-viewDidUnload-dealloc
- From: Scott Andrew <email@hidden>
- Date: Thu, 21 Apr 2011 10:51:35 -0700
I put my iVars in my header for debugging reasons. I just looked at some code that was new to me with no iVars in the header and got tired of "po" when i needed to see something. I think ivars as private members in a class is not a bad thing. I also tend to only expose what i want the outside world to use through properties. If its not meant for anyone else's consumptions or inquiry it stays an ivar and the class access it directly.
On Apr 21, 2011, at 4:06 AM, Jean-Denis Muys wrote:
>
> Le 20 avr. 2011 à 03:18, "David Hoerl" <email@hidden> a écrit :
>
>> The only possible downside I can see to removing the ivars is that subclass usage must use the "self.property" form, which many knowledgeable people have said should have been used in the first place.
>>
>
> In my experience there is another downsize: any property not backed by an explicit ivar is not visible in the debugger. This annoying behavior is the reason why my pattern is now to declare all my property ivars (public and private) in the class extension.
>
> The downside of *that* is that my code is now only compatible with LLVM, as GCC doesn't support ivars in class extensions.
>
> Finally I now set all my deallocated ivars to 0xDeadBeef instead of nil, with the goal of crashing early if I reuse them.
>
> JD
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden