Also, if you're unsure whether you're following ref-counting rules correctly, the static analyzer in Xcode will give very detailed warnings about incorrect uses. Just another way to determine if you're using ref-counting correctly.
Doug Hill > On Aug 24, 2016, at 2:49 PM, Doug Hill <cocoa...@breaqz.com> wrote: > > Wim, > > If I may paraphrase: > > The reference counting semantics are only interesting to the caller when the > callee returns an object. What the callee does with a setter is entirely the > responsibility of the callee to make sure it follows ref-counting rules. For > example, a setter may not involve a property or iVar at all, it could be pure > side-effects. In terms of ref-counting semantics, the caller doesn't have a > clue or need to care what happens > > In this particular case, it would appear that the NSTextField holds a > reference the 'formatter' object via the similarly-named property in > NSControl. While it might be good to know it's a property so we can make use > of property syntax correctly, how it goes about keeping a reference to this > object is unimportant to the caller. > > Doug Hill > > PS > IMHO using manual ref-counting because there is a perceived time-savings from > learning ARC is generally a bad argument. The amount of time trying to figure > out all the manual ref-counting rules, and making sure your code follows them > perfectly, is probably much better spent learning ARC and applying it > correctly. And likely results in more maintainable and understandable code. > The argument in favor of ARC is especially better if you own the code in > question and there isn't much code to write. > > PS #2 > ARC is available in OS X 10.6 as "ARCLite" e.g. "Automatic Reference Counting > without zeroing weak reference." > If you don't require the weak attribute semantics in your own code, then you > should be able to use ARC. > > https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ObjCAvailabilityIndex/ > > >> On Aug 24, 2016, at 1:41 PM, Wim Lewis <w...@omnigroup.com> wrote: >> >> >> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn <andr...@falkenhahn.com> >> wrote: >>> I have read Apple's memory management guide on retain/release and >>> I think I've basically got it, but there's just one thing that >>> I'm not confident about and that is "setXXX" methods which accept an >>> NSObject parameter and I don't know how I can know whether the >>> "setXXX" retains or not. >> >> In general, if a method you call wants to keep a reference to an object you >> pass in, it is that method's responsibility to retain it (or copy it, or >> whatever). If it doesn't hold on to the formatter, then it won't retain it. >> The goal of reference-counting, whether ARC or not, is that all that >> information can be safely considered an implementation detail of the method >> you call, and not something you need to worry about. >> >> Delegate and data source setters are an unusual, exceptional case: an object >> with a delegate typically doesn't retain its delegate, just keeps a >> reference to it. This is dangerous, since the delegate can get deallocated, >> leaving a dangling pointer (--> soon you'll crash). If the API conventions >> were being formed today, delegates would probably be 'weak' pointers, but >> since they predate the existence of weak pointers they get the "slightly >> dodgy poor-man's weak pointer" behavior of simply not retaining. Why is >> this? It's to avoid retain-cycles, since very often, an object's delegate is >> its (direct or indirect) owner in a conceptual sense and therefore already >> retains the object. >> >> >>> Post-scriptum: Yes, I know, there's now ARC and everything and >>> all those retain stuff shouldn't be used anymore >> >> ARC just automatically inserts the same retain/release calls that you would >> have written manually. (Plus some optimizations on top of that, but that's >> the basic idea.) It can be useful to understand MRR even if you don't write >> it. >> >> On Aug 24, 2016, at 1:24 PM, Andreas Falkenhahn <andr...@falkenhahn.com> >> wrote: >>> If it retains, I could just do the following: >>> >>> [textField setFormatter:formatter]; >>> [formatter release]; >>> >>> And I wouldn't have to worry about "formatter" any longer. >> >> Yes, you can do exactly that. If the textField needs the formatter to >> continue to exist after -setFormatter: returns, it will retain it. It's the >> textField's job to worry about that retain/release, not yours. You only need >> to retain objects that *you* have a reason to reference in the future. > > > _______________________________________________ > > 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/cocoadev%40breaqz.com > > This email sent to cocoa...@breaqz.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
