[swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Dave Abrahams]

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
>     <swift-evolution at 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 at swift.org> wrote:
>
>             on Sun Apr 10 2016, Dietmar Planitzer <swift-evolution at 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.

-- 
Dave