Re: Does setFormatter() retain?
Re: Does setFormatter() retain?
- Subject: Re: Does setFormatter() retain?
- From: Doug Hill <email@hidden>
- Date: Wed, 24 Aug 2016 15:14:49 -0700
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 <email@hidden> 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 <email@hidden> wrote:
>>
>>
>> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn <email@hidden> 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@hidden> 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@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden