on Mon Apr 11 2016, Charles Srstka <cocoadev-AT-charlessoft.com> wrote:
> On Apr 11, 2016, at 12:03 PM, Dave Abrahams via swift-evolution > <[email protected]> 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 > > <[email protected]> wrote: > > on Sun Apr 10 2016, Dietmar Planitzer <[email protected]> > > 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. -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
