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

[Jonathan Hull]

My main point was that, this was an extremely common practice in Objective C (one which was even used/encouraged by Apple for quite a while) and the proposal needs to address it.  There is a lot of working code out there that uses this pattern.  In short, we need to be careful not to accidentally trip all of those magical behavior changes you were talking about, since it would effectively break that code.

It is one thing to say that there is a better way to approach this problem for new code in Swift… it is another entirely to say that code written this way years ago in ObjC (and which works today with Swift) can’t be used with Swift 3.0 without a major refactoring effort.

Thanks,
Jon

P.S.  I will leave my secondary point (that I would like to see more of Smalltalk’s abilities in Swift) alone for the most part, since it seems to be distracting from my main point that the proposal would break code which currently works.

> Table view semantics were discussed at length on a prior version of the
> thread. That pattern is less than ideal; it essentially creates magic
> behavior that's only described by documentation… or, worse, completely
> forgotten about in documentation; something changing from version to
> version of the framework; etc. I can not tell you how many times this
> has tripped up members of my teams. Over in Cocoa proper, similar
> behavior changes also arise (usually performance optimizations) from
> whether or not you *override* a method, and it's even more confusing.
>  
> Such a practice should not be a cornerstone of a modern language; as
> discussed in the prior thread, the different semantics of the measuring
> methods (the current return values, as well as the implicit one from not
> overriding) should be captured explicitly in an enum, with a clear
> default return value. This is in line with the spirit of Swift. Your API
> contract with the user is clear, and the introduction of default
> implementations is versioned as a matter of public API.
>  
> It's interesting that you use the phrase "customization points". Our
> text for teaching protocol extensions in Swift uses it heavily - that
> *is* the behavior of protocols with default implementations in Swift
> today. You delegate something out, but give it a default implementation
> with logic you specify. That's a customization point, too.
>  
> Cheers!
> Zachary Waldowski
> zach at waldowski.me <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160408/0105d09f/attachment.html>