Hi Jens,
On Apr 25, 2013, at 18:10 , Jens Alfke <j...@mooseyard.com> wrote: > On Apr 25, 2013, at 1:20 AM, Oleg Krupnov <oleg.krup...@gmail.com> wrote: > >> This breaks encapsulation of objects with block properties (e.g. >> MyAnimation.completionBlock) > > I understand the problem you're describing (and yes, I've had a couple of > memory leaks resulting from it) but I don't understand how you think it's > breaking encapsulation. Seems pretty obvious to me: blocks capture variables from their lexical scope implicitly and then let them escape this scope. I explain this (briefly) in my HOM paper: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.65.4687 Sometimes that is exactly what you want, but often not. Especially for multi-threading applications you want to explicitly control what you share, not have it implicitly captured. >> It seems to me that it's much better to drop the convenience of blocks >> in favor of safety and full control of retain/assign relationships >> between my objects. > > It's a subjective decision, but for what it's worth, I disagree. Blocks are > so useful that it's not worth giving them up. In any case, you're talking > about only one use of blocks — as a way to tell an object an action to > perform later, a replacement for delegates or target/action pairs. I'd agree that these are application areas that blocks are not really well suited for. For processing something later, I do think the HOM approach is simpler: [[self afterDelay:0.1] pollSearchResults]; Target-action also seems ill-suited to blocks, and IMHO if Objective-C had had blocks at the time, IB would have been much less useful. > There are plenty of other good uses for blocks that don't have these issues. Agreed! For example "around" processing. No more -lockFocus / unlockFocus, gsave/grestore etc. > In my code, most of the places I use a block as an onXXX property value it's > going to be called exactly once. What I do then is, in the caller, set the > corresponding _onXXX ivar to nil after calling through it, to break cycles. > > - (void) xxxHappened { > if (_onXXX) { > _onXXX(); > _onXXX = nil; > } > } Interesting. I can see how it works, not quite seeing how that would be a common idiom...but curios! Cheers, Marcel _______________________________________________ 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
