> On Apr 11, 2016, at 11:41 , Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote: > > > on Mon Apr 11 2016, Charles Srstka <cocoadev-AT-charlessoft.com > <http://cocoadev-at-charlessoft.com/>> wrote: > >> On Apr 11, 2016, at 12:03 PM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> on Sun Apr 10 2016, Dietmar Planitzer <dplanitzer-AT-q.com> wrote: >> >> On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution >> >> <swift-evolution@swift.org> wrote: >> >> on Sun Apr 10 2016, Dietmar Planitzer <swift-evolution@swift.org> >> >> wrote: >> >> I’m not sure whether you’ve read the conclusion of my >> mail since >> you’ve only commented on the introductory part. In the >> conclusion I >> wrote that a possible approach for the replacement of >> ObjC-style >> optional protocol methods would be: >> >> 1) the default implementation of a protocol method must be >> defined >> >> in >> >> the protocol (so just like in native Swift protocols >> today). >> >> ? They can and must be defined in protocol extensions today. >> >> I know. >> >> 2) we add a way for a protocol provider to check whether the >> >> protocol >> >> adopter has provided an “override” of the default method. >> >> I object to this part. >> >> You object why? I do understand why you object to the ObjC model since >> there is not necessarily an implementation of the protocol method and >> thus the protocol provider has to guard every call with an existence >> check. But in this model here we would be guaranteed that there would >> be an implementation of the protocol method and thus guarding the call >> wouldn’t be necessary. >> >> Because it's a needless complication that will encourage protocol and >> algorithm designers to create inefficient programs because they know the >> user can fall back on this hack. Nobody thinks that classes need the >> ability to check whether a given method is overridden. Why should this >> be needed for protocols? >> >> Actually, Apple’s frameworks have often contained code to check whether given >> methods are overridden, and this has allowed them to deprecate override >> points >> and replace them with better API without breaking source or binary >> compatibility. The most obvious example that comes to mind is NSDocument; >> when >> they introduced the newer override points such as -readFromURL:ofType:error: >> that used NSURLs instead of paths and allowed returning an NSError, they >> added >> code in the default implementation to check whether the subclass overrode the >> older -readFromFile:ofType: method and if it did, called that method. >> Otherwise, >> it would call the modern methods. This way, older applications that were >> still >> overriding -readFromFile:ofType: would continue to work correctly. > > I don't believe we're aiming to support this kind of evolution in Swift, > but others understand our resilience plans better than I, so we should > probably let them comment.
It's a useful enough pattern that I wouldn't want to rule it out entirely, but it's rare enough that it could be some strange runtime call. (Also, in many cases there's a simpler implementation, like "call the old method unilaterally".) Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
