<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">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
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">zach at waldowski.me</a></pre></blockquote><div class=""><br class=""></div></div></div></div></body></html>