Re: ARC and IBOutlet - strong vs weak......
Re: ARC and IBOutlet - strong vs weak......
- Subject: Re: ARC and IBOutlet - strong vs weak......
- From: Gerd Knops <email@hidden>
- Date: Sun, 06 Dec 2015 08:56:19 -0600
"weak" is also inherently incompatible with KVO, because no notification is sent when the weak reference goes away. And that'll wreak havoc, especially when you are using Cocoa Bindings.
Gerd
> On Dec 6, 2015, at 05:52, Dave <email@hidden> wrote:
>
>>
>> On 4 Dec 2015, at 18:04, Quincey Morris <email@hidden> wrote:
>>
>> On Dec 4, 2015, at 06:16 , Dave <email@hidden <mailto:email@hidden>> wrote:
>>>
>>> I asked about this on Twitter to an engineer on the IB team and he confirmed that strong should be the default and that the developer docs are being updated.
>>
>> That sounds like a definitive answer. So you’re asking us because … why?
>
> Because else where it says “weak” and when you create a Class where XCode pre-generates outlet properties it uses weak as the attribute. Which tends to suggest that they should be weak?
>
>> Here’s how I understand the situation:
>>
>> If you use a NSWindowController or NSViewController subclass to load the nib, the controller keeps strong references to all the top-level objects in the nib. That means all referenced objects in the nib stay alive, too — which is to say, all of them, since the nib is a hierarchy of references. (The only exceptions would be if relationships are changed directly by code, which is therefore not a good idea.)
>>
>> So, from that point of view, it’d be fine for all outlets to be weak.
>>
>> However, when windows close or views are swapped out, you don’t have control of the order of deallocation of the controllers, which means that the owner of an outlet may see the outlet go to nil if the controller is deallocated first.
>>
>> If the outlet owner can tolerate its outlets becoming nil, then that’s fine too, and the outlets can be weak.
>>
>> But sometimes is tricky to handle this without crashes. (That’s why, for example, it’s often useful to nil out the ‘delegate' property of some object that’s using the outlet owner. It prevents delegate methods being called and possible using a stale or nil reference to something.) It’s easier to make the outlets strong — not to keep them alive generally, but specifically to keep them alive as long as their owner.
>>
>> That’s an easy answer, but if that happens to cause retain cycles, then you need to find a solution to *that* problem, which might be using a weak outlet after all, or dealing with the situation in some other. (Nil-ing out a strong delegate property also helps with this problem, often.)
>>
>> Summary: it’s not so very complicated, but there’s no single answer that always works. "Always making your outlets strong, except when you are solving a reference cycle", sounds like a good rule of thumb.
>>
>
> Thanks for the brilliant explanation and I agree making them strong unless they need to be otherwise seems like a good rule of thumb.
>
> All the Best
> Dave
>
> _______________________________________________
>
> 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