Re: ^Block statement considered harmful for callbacks?
Re: ^Block statement considered harmful for callbacks?
- Subject: Re: ^Block statement considered harmful for callbacks?
- From: Oleg Krupnov <email@hidden>
- Date: Thu, 25 Apr 2013 23:32:26 +0300
>
> On the other hand, delegates add the problem that they desiccate the code for dealing with the results from the code for setting up the request in the first place. I would consider that a much much much higher penalty than having to a bit careful about retain cycles.
>
You are correct, and that was why I switched ruthlessly to blocks instead of delegates for callbacks... Until I found this nasty problem with retain cycles, which doesn't actually have an elegant solution, and the workarounds leave ugly scars in your code and an uneasy feeling of suspicion to every line of your code in blocks.
In fact, blocks only give you an illusion of all code in one place, but just as with delegates, it is "dissected" in time, and personally I always find it more difficult to read code with blocks, because it takes me an effort to understand the context the code will ge running in, across the block scope. Now if you add the necessity to think about retain cycles, it's pretty much a nightmare.
After some time of using blocks, after their novelty worn off, personally I don't find them so much more convenient for callbacks as they initially seemed (even if there were no retain cycles, which are there, don't forget). It is not always relevant to place the callback code in the same place where I set up the worker object, and I often find myself calling a single method in the block that does the callback down the code, like I would do with delegates. Besides, it's quite tricky with blocks if you need to cancel the previous worker and replace it with a new one, whereas with delegates you can simply retain the current worker and compare it with the callback's sender.
All in all I come to personally find delegates more elegant and honest than blocks for callbacks. Am I alone here? :)
_______________________________________________
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