> On Mar 31, 2016, at 5:51 PM, David Waite via swift-evolution > <[email protected]> wrote: > > +1 > > We need to support optional methods in @objc protocols because it is required > for interoperability. However, there are in my experience only reasons for an > optional protocol method: > > - There is a very common default behavior for a delegate (such as return > immediately with a value of 0/nil/false) which would be a burden to require > everyone to implement. We can instead accomplish this with protocol extensions > > - The absence of a method in a delegate indicates a behavior that is > otherwise impossible for the delegate to implement. The easiest example of > this would be tableView:heightForRowAtIndexPath:, where the absence triggers > an optimization where UITableView.rowHeight is used for all math, and its > presence means that performance will be degraded, and the delegate will be > called repeatedly for every single index path in order to figure out the > table positioning/scroll height. I believe this has been shown to be much > better solved via an optional additional protocol conformance to indicate > that you are supporting a different ‘class’ of behavior, in this case that > might be something like UITableViewVaribleHeightDelegate.
+1. I am not fully pleased with the design of the UITableViewDelegate and UITableViewDataSource protocols and this is one point that is problematic. It makes it impossible to implement a generic delegate that might sometimes need to have variable row height, but in other cases should take the fast path. > > I’d hate for there to be a push for optional protocol methods just because it > can be confusing which methods are required in swift protocol implementations > (vs defaulted by a protocol extension). > > -DW > >> On Mar 31, 2016, at 12:23 PM, Dave Abrahams via swift-evolution >> <[email protected]> wrote: >> >> >> on Wed Mar 30 2016, Yuval Tal <[email protected]> wrote: >> >>> Hi, >>> >>> I find that optional protocol methods to be very useful. However, >>> there is a caveat -- it needs to be mapped to @objc. This puts a set >>> of limitations, such as: structures cannot be used as parameters as it >>> does not map to objective-c. What do you think about removing the >>> requirement of using @objc and allow to create optional methods >>> without these limitations? >> >> Caveat: this is going to be strongly-worded; sorry in advance. I think >> (no offense intended) it's a terrible idea. The whole notion of an >> “optional requirement” is nonsensical to begin with, and the use of >> optional protocol requirements encourages a style of programming that >> lifts the responsibility of the protocol designer for careful design at >> the expense of clients of the protocol. There are better ways to do >> things; let's not propagate this anti-pattern any further than it's >> already gone. >> >> -- >> Dave >> >> _______________________________________________ >> 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
