To be fair, the "spirit of UIKit" that you mention comes from a time and language that encouraged OO and OO alone. Optional methods are, more often than not, backed by gigantic bit fields that keep track of whether or not the delegate actually conforms to the entirety of a protocol, which opens up a huge vector for bugs and complicates the internal logic of the control. I think Swift gives us a better opportunity to rethink the old approach not encourage it, don't you think?
For example, using a method returning an optional (or even better, a proper value) means you can give a proper semantics for what it means to not implement a particular method rather than "no selector here". ~Robert Widmann 2016/03/31 14:49、Yuval Tal via swift-evolution <[email protected]> のメッセージ: > None taken. However, most of the delegate concept of UIKit relies heavily on > this "nonsensical" requirement. It is impossible for someone to implement a > control in swift which is "in the spirit" of UIKit, meaning the control has a > delegate, with several methods that share the same name with different > parameters, some are required and some are optional. I think it is not fair > to tell users that they cannot implement something that is such a common and > repeating pattern in the core. > >> On Thu, Mar 31, 2016 at 2: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
