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

[Jordan Rose]

> On Apr 11, 2016, at 11:41 , Dave Abrahams via swift-evolution <swift-evolution at 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 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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160411/6bf60d0b/attachment.html>