On Aug 27, 2016, at 13:55 , Andreas Falkenhahn <andr...@falkenhahn.com> wrote: > > I still don't know whether setting the delegate to nil > before release is a general rule or does it only apply to NSTableView?
It’s not clear what delegate you mean by “button delegate”, but it doesn’t really matter. Delegates are not a special case of the rules, just a case where you need to pay attention to what the rules imply. A “delegate” property is “strong”, “zeroing weak” or “unsafe”. (The terminology or syntax keyword for each of these has varied over time and context.) If it’s strong or zeroing-weak, there’s no need to set the property to nil. If it’s unsafe, you generally should set it to nil before you allow the lifetime of the delegate object to end. Therefore, you can look in the API for the property — definitively, in the SDK you’re building against — and determine which of the above ownership types the property uses. Note that you will see some inconsistencies in ownership types in different parts of Cocoa. That’s because the delegate pattern was standardized somewhere around 10.5, but older APIs may have been different and cannot be changed without breaking source and/or run-time compatibility. There are a few real exceptions, which are historical relics, and documented (I think) in the ARC transition guide: — ARC-compatible ownership rules are supported back to (something like) 10.5, but zeroing weak pointers weren’t supported until (IIRC) 10.6.8. In the interim, zero weak properties were actually unsafe. — A very few classes (NSWindowController was one of them) did not support the zeroing weak mechanism (I mean pointers to objects of these classes, not references within these classes to objects of other classes). I believe these have all been corrected now, but you might need to be aware of which OS version they changed in, if you’re supporting older deployment targets. Or, avoid depending on the zeroing part of the behavior. Incidentally, while it might be a noble goal to have your software support OS versions all the way back to 10.6 or 10.5, there are good reasons for moving on to later deployment targets. OS X really has gotten better over the years, and way-back support starts to become more a source of bugs than a source of compatibility. Lastly, I may have lost track of things during the series of threads we’ve had about memory management in your app, but I can’t now understand why you don’t adopt ARC. I guess I thought it was because you were maintaining existing code, which presumably did its manual memory management properly. But if you’re writing new code, or even updating old code, there is literally no downside (AFAIK) in switching to ARC. Isn’t it a positive upside in source files shared between Mac and other platforms of your app, to not need retain and release calls? Note also that ARC and manual memory management can be intermixed in the same target freely (though not in the same source file), provided the existing manual memory management does follow the rules. Since you’re not 100% familiar with the rules, why not just switch to ARC? _______________________________________________ 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
