+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. 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
