On Aug 1, 2014, at 12:03 , Jerry Krinock <je...@ieee.org> wrote: > Unfortunately, I’m not able to justify my design pattern based on the Cocoa > Bindings API documentation.
As I said earlier in the thread, that fact that the error messages go away doesn’t mean the problem doesn’t exist. However, I think you’re correct that a good-enough solution is here good enough. > Looking through my code, although I never really gave this too much thought, > it appears that I tend to -unbind: when in doubt. I’d suggest sprinkling around the setting of relationships to nil (KVO compliantly). If you do that, bindings will take care of themselves, and you’ll deal with more cases (that is, observations that aren’t bindings). The other thing we’ve got going for us is that we know *when* the whole structure needs to be brought down — when the window closes, or when the document closes, depending on which properties we’re talking about — and our code can act accordingly. This is not true in the general case of old GC code that implicitly relied on a “finalization is eventual resource release” heuristic. As a side effect of this last knowledge, Sean could actually solve his weak reference observation problem (though it was not, as it turned out, the cause of the error messages in this case) by changing the references back to strong, and manually breaking cycles at close time. It’s nicer not to have to do this, but it’s certainly feasible. Rambling on… I think Swift’s take on the referencing part of this problem is interesting. For a situation like this, where the objects have basically the same lifetime, as the document, window controller and view controller do in this case, Swift encourages you to use ‘unowned’ references rather than weak references to avoid the reference cycles. That’s not quite as scary as the equivalent ‘__unsafe_unretained’ in Obj-C, because such references in Swift are *guaranteed* to crash if used after the referenced object has been deallocated. In Obj-C, of course, it’s a matter of luck whether it crashes. Unfortunately, Swift has nothing to say (yet) on the subjects of KVO or observations, but we live in hope. _______________________________________________ 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
