On Dec 4, 2015, at 06:16 , Dave <d...@looktowindward.com> 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? 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. _______________________________________________ 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
