RACDelegateProxy vs Common Delegate implementation

Question

I'm studying the ReactiveCocoa(I'm not good with FRP, neither with pure functional programming) and i saw the RacDelegateProxy class that can abstract the implementation of the delegate methods with a void return value. What i didn't get well is what are the benefits of using it, when we compare with the traditional implementation, that is implementing each method and getting the calls. So, what are the main differences and benefits of using the RACDelegateProxy rather than implementing in a traditional manner?

Code example(Using ReactiveCocoa):

self.deselectDelegate = [[RACDelegateProxy alloc] initWithProtocol:@protocol(UITableViewDelegate)];
[[self.deselectDelegate rac_signalForSelector:@selector(tableView:didDeselectRowAtIndexPath:)]
 subscribeNext:^(RACTuple *arguments) {
     // code ...
 }];

VS(traditional implementation):

- (void)tableView:(UITableView *)tableView didDeselectRowAtIndexPath:(NSIndexPath *)indexPath {
    // code ...
}

Answer 1

Your question can be generalised to "What are the advantages of signals over callbacks".

There used to be a link on RAC's github repo called Escape from Callback Hell - link is no longer working, but I think that title highlights the point perfectly.

Basically, one of the advantages of FRP is transforming all asynchronous patterns (KVO, delegates, notifications, ...) into signals, which results in:

• simple comosition: Have you ever tried chaining multiple network operations? It's quite a drag with standard approaches. And you might even need to add some database operations or location updates into your asynchronous chain...

• improved readability and easier maintanance: related code is in the same place, not all over the class in the form of callbacks.

---

Edit

Found mentioned article archived: Escape from Callback Hell