Very good points Dietmar, but there is one more bit about default implementations in extensions that makes it worse to use than the old Objective-C model... the complex dispatch rules that can make the executed method type dependent and not instance dependent. We really need dynamic dispatch there to make it work.
[[iOS messageWithData:ideas] broadcast] > On 2 Apr 2016, at 02:50, Dietmar Planitzer via swift-evolution > <[email protected]> wrote: > > That’s an interesting idea. Although I still do not like the fact that the > Swift model forces me to split up the implementation between the delegating > type and the delegate whereas the ObjC model allows me to keep the default > and non-default implementation in a single place, namely the type. > > There are some additional questions that I think have not received a > satisfactory answer yet: > > a) the ObjC model makes it straight forward to ADD new functionality to a > delegate without breaking existing apps. Eg the > tableView(heightForRowAtIndexPath:) method was added in Mac OS X 10.4. Before > that the NSTableView did not support variable row heights. The only change to > the API that Apple had to introduce in order to allow apps to create tables > with variable row heights was this one optional delegate method. App > implements it -> table view stores a per-row height; app does not implement > it -> table view uses a fixed row height which is set as a property on the > table. And so existing apps would continue to run with the new AppKit version > just fine. > > How would this work in the Swift model? > > > b) the ObjC model allows for significant and in some cases important > optimizations: > > b1) NSTableView support fixed and variable row heights. Layout can be much > simpler for fixed row heights and there is no need to store the per-row > height in an internal cache. In the ObjC model the table view has an > efficient means to detect whether the delegate wants fixed or variable row > heights since all it needs to do is check whether the > tableView(heightForRowAtIndexPath:) is implemented. If it is -> call it for > every row and cache the row height and enable the variable row height layout > code; otherwise -> do not cache per row heights and enable the fixed row > height layout code. Note that the code that does the actual heavy duty work > (the layout code) may be far remove from the code that calls the > tableView(heightForRowAtIndexPath:) method. In the Swift model though, we > would have to invoke the tableView(heightForRowAtIndexPath:) for every row > and compare the return results before we could even decide if the delegate > wants variable or fixed row heights. > > b2) the ObjC model allows me to get the implementation of the optional > delegate method which in turn allows me to completely remove dynamic dispatch > from the performance critical path. > > How would these things work in the Swift model? > > > Regards, > > Dietmar Planitzer > > >> On Apr 1, 2016, at 18:20, Rob Mayoff via swift-evolution >> <[email protected]> wrote: >> >> >> class UITableView { >> ... >> private func addRow(at indexPath: NSIndexPath) { >> ... >> cell.size.height = delegate?.tableView(self, >> heightForRowAtIndexPath: indexPath) ?? rowHeight >> ... >> } >> ... >> >> You need not duplicate the default logic: >> >> private class DefaultDelegate: NSObject, UITableViewDelegate { } >> private let defaultDelegate = DefaultDelegate() >> >> public class UITableView { >> >> private func addRow(at indexPath: NSIndexPath) { >> ... >> cell.size.height = (delegate ?? defaultDelegate).tableView(self, >> heightForRowAtIndexPath: indexPath) >> ... >> } >> >> } >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
