No comments yet.
Callbacks make sense for UI widgets. In this case, the programmer is not the one generating the event, the user is.
But when the programmer is initiating some high-latency request with a completion event, why not just expose synchronous functionality and let it be composed and made asynchronous using blocks?
The control flow for chaining delegate callback based class functionality is so disgusting! Think about it. You send a message. Later, control flow continues at some point which, in the standard cocoa delegate pattern, i can only discern by looking at your documentation or headers. In addition, if there are multiple points where the initial message might have been sent, i may even have to DEMULTIPLEX using some state i have kept on the initial message send points to determine which is which. At this point, i might even send ANOTHER message with a callback, which i also have to track through documentation and track with my eyeballs through some crappy ad-hoc demultiplexing if statement because there is no general language facility for handling this problem. Also, you may or may not be able to determine the context of the send using just the method parameters. YUCK!
Finally, my question: Don't you agree? Why don't we prefer to expose synchronous functionality when possible and let the user compose it using blocks and either operation queues or grand-central dispatch? In this way, not only is the control flow actually parseable, but the user has more control over parallelism. Keep your callbacks for status updates and this sort of thing.
