[tolmasky]

Regarding delegation, I feel both closures and delegation have their place. We have been adding closure-based API in the areas we feel make sense (things that have a single expected callback return for example). However, I feel that things like TableView delegates and data sources still benefit much more from the delegate model than the closure model, and yes its because its more restrictive. If you look at NSTableView, it has many many datasource and delegate methods that are intricately related, and forcing you to group them in an object leads to better code in my opinion.

Perhaps more importantly, delegates and data sources allow you to do the Interface Builder-style visual development that we are aiming for. There really is no way to do this sort of thing with closures, unless you consider "double click on an object and type some code" to be visual development, which I do not. This is why I think closures make a lot of sense for things like network connections, callbacks for panels, etc. but less sense for things that in the common case really do represent connections and interactions between objects.

Interestingly though, we have recently been thinking of ways of "allowing both" easily. In other words, either making everything closure based behind the scenes and providing additional APIs for delegate, or making everything delegate based and transparently creating anonymous delegate objects for closures.

[tumult]

Yeah I find that delegation makes more sense in an OO context when the states between the delegate and other object are closely entwined. TableView data source is a perfect example, basically the two states need to stay consistent with each other but provide several standardized methods for modifying or reporting changes to state, which is where I think delegate methods shine. "Just waiting for something to return" is where I think they tend to be cumbersome when you have lambdas at your disposal.

In this regard I think JS and Obj-C are now starting to converge, which is interesting.