Actually I would like to have this suggestion in any case, where I have declared a property that allows me to set it using dot-notation - because then I feel confident, that memory management is handled correctly. Of course if the property is declared as readonly, it will not work (and should not be suggested).
I think the suggestion self.var = nil; will be alright if variable is retain or assign - of course if it is assign, then you really don't need to do anything about it, when you're in dealloc - however, I consider it good coding style, because it shows, that you're aware of the variable - and *if* somebody should change the property from assign to retain later on, then dealloc does not need to be modified.
If property is assign, you have not retained when the value was initially set - therefore you should not release.
This is in fact my best argument for using self.ivar = nil; in dealloc. It will do the correct thing regardless of whether you set the property to retain or assign. (unless you have manually implemented the setter) :-)
I meant if we have "ivar = [class retain]" and some property was synthesized with this ivar with "assign" attribute, we'll have to put "[ivar release]" to dealloc method, "self.property = nil" will be incorrect here.
However, I would consider it bad practice to declare a property with assign, and then do stuff in my implementation where I actually retained it - how about having an intention to warn about that? :-)
Filed a request for it - OC-685. You can vote for it.
I expect you want the suggestion to be:
self.var = nil;
aren't you leaking memory, if it's just:
var = nil;
You are right.
self.var = nil; when variable is retain
Actually I would like to have this suggestion in any case, where I have declared a property that allows me to set it using dot-notation - because then I feel confident, that memory management is handled correctly. Of course if the property is declared as readonly, it will not work (and should not be suggested).
I think the suggestion self.var = nil; will be alright if variable is retain or assign - of course if it is assign, then you really don't need to do anything about it, when you're in dealloc - however, I consider it good coding style, because it shows, that you're aware of the variable - and *if* somebody should change the property from assign to retain later on, then dealloc does not need to be modified.
If property is assign, inserting "self.prop = nil" is incorrect, because it won't release the underlying ivar.
Fixed. The option is in Preferences | Code Style | Code Generation.
I would beg to differ.
If property is assign, you have not retained when the value was initially set - therefore you should not release.
This is in fact my best argument for using self.ivar = nil; in dealloc. It will do the correct thing regardless of whether you set the property to retain or assign. (unless you have manually implemented the setter) :-)
Thanks for fixing...
I meant if we have "ivar = [class retain]" and some property was synthesized with this ivar with "assign" attribute, we'll have to put "[ivar release]" to dealloc method, "self.property = nil" will be incorrect here.
I agree with you on that.
However, I would consider it bad practice to declare a property with assign, and then do stuff in my implementation where I actually retained it - how about having an intention to warn about that? :-)