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 <[email protected]> wrote: > > > On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn <[email protected]> > 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 <[email protected]> > 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 ([email protected]) 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 [email protected]
