"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 <d...@looktowindward.com> wrote: > >> >> On 4 Dec 2015, at 18:04, Quincey Morris >> <quinceymor...@rivergatesoftware.com> wrote: >> >> On Dec 4, 2015, at 06:16 , Dave <d...@looktowindward.com >> <mailto: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? > > 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 (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/gerti-cocoadev%40bitart.com > > This email sent to gerti-cocoa...@bitart.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
