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

[Charles Srstka]

> 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 <http://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.

Charles

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