<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=""><div class=""><blockquote type="cite" class="">El 26 feb 2016, a las 13:11, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> escribió:</blockquote><br class=""></div><div class="">This is a review of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md" class="">[SE-0026 "Abstract classes and methods".](https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md)</a></div><div class=""><br class=""></div><div class="">I am <b class="">**against**</b> the acceptance of this proposal:</div><div class=""><br class=""></div><div class="">- It lacks a clear problem.</div><div class="">- The leap from a nebulous problem to abstract classes as the solution is a <i class="">*non sequitur.*</i></div><div class="">- Its arguments are insufficient to justify the complication it would add to Swift, which is contrary the simplification and clarification aims of the Swift community.</div><div class=""><br class=""></div><div class="">The contrast is sharpened by comparison to the Python Enhancement Proposal that accompanied the introduction of abstract base class into Python. The present proposal fails to provide a correspondingly thoughtful rationale.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">## No Clear Problem</b></div><div class="">The proposal itself does little to define a practical problem, and less to explain how abstract classes solve this problem better than alternatives. It feels like a solution in want of a problem, which is the opposite of a considered addition to the language.</div><div class=""><br class=""></div><div class="">As best I can determine, the primary problem introduced is that of wanting to have abstract properties. The example given is better resolved by providing the <font face="Menlo" class="">`url`</font> as a constructor argument, as <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011207.html" class="">[noted by Stephen Celis.](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011207.html)</a> Further, the immediate solution appears to be to argue in favor of <a href="https://en.wikipedia.org/wiki/Uniform_access_principle" class="">[uniform access](https://en.wikipedia.org/wiki/Uniform_access_principle)</a> as found in Self and Eiffel, not abstract base classes, which compound non-uniform access by a further serving of complexity.</div><div class=""><br class=""></div><div class="">Another problem mentioned is lack of easy delegation of implementation in the context of protocols; providing a simple way to proxy calls to another object would present a promising and useful avenue for resolving this problem that would also compose more generally with the rest of the language. <font face="Menlo" class="">`NSProxy`</font> has always been somewhat awkward in this regard; perhaps we can do better in Swift?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">## No Clear Significance</b></div><div class="">Without a clear problem to address, it becomes difficult to evaluate the significance of the problem.</div><div class=""><br class=""></div><div class="">Ultimately, it's unclear precisely what the problem under consideration is, unless the problem is stated simply as, "Swift doesn't have abstract base classes." If that is the true problem considered to address, then it seems especially insignificant; Swift also lacks good support for relational programming à la mini-kanren, but a difference does not a problem make.</div><div class=""><br class=""></div><div class="">If we focus on "no abstract classes" as the problem, then the problem appears insignificant: Smalltalk and Objective-C have both made do without formal support for abstract classes. Objective-C went so far as to remove `subclassResponsibility` from the common language vocabulary, which eliminated all inbuilt support for abstract classes. Never have I heard either Smalltalker or Obj-C hacker end up despondent and cursing over the lack of built-in abstract class support in these languages.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">## Compared to Python's Rationale for Adding Abstract Classes</b></div><div class="">It is interesting to consider the motivation for adding abstract base class support to Python as explained in <a href="https://www.python.org/dev/peps/pep-3119/" class="">[PEP 3119](https://www.python.org/dev/peps/pep-3119/).</a></div><div class=""><br class=""></div><div class="">In Python's case, the decision was motivated by the desire for a reliable means to test particularly for some shared quality of a group of objects - basically, a reliable `respondsToSelector:` or `isKindOfClass:` that allows detecting this quality without incidental risk of false positives or negatives (<a href="https://www.python.org/dev/peps/pep-3119/#rationale" class="">["Rationale"](https://www.python.org/dev/peps/pep-3119/#rationale)</a>).</div><div class=""><br class=""></div><div class="">As a result, Python adopted abstract base classes as an alternative to interfaces (<a href="https://www.python.org/dev/peps/pep-3119/#abcs-vs-interfaces" class="">["ABCs vs. Interfaces"](https://www.python.org/dev/peps/pep-3119/#abcs-vs-interfaces)</a>). But Swift already has interfaces in the form of protocols; this answers the need that motivated the addition of abstract base classes to Swift.</div><div class=""><br class=""></div><div class="">Because we cannot borrow the rationale used for adding abstract base classes to Python, and the document before us spends its effort explaining abstract base classes rather than the problem they would solve, it remains for those arguing for the added formal complexity of abstract base classes to motivate their addition in the context of Swift. The current proposal is manifestly lacking in this regard.</div><div class=""><br class=""></div><div class=""><b class=""><br class=""></b></div><div class=""><b class=""># Out of Alignment with Swift</b></div><div class="">Adding abstract class support to Swift seems unprincipled. I cannot see what problem would be solved, and Swift is working towards considered language growth, and even better, language contraction, at this point in time. Adding abstract base classes would feel like nodding to feature agglutination by cargo cult, not the careful evolution we aspire to.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class=""># Effort</b></div><div class="">I read the article and then looked at the arguments in favor of supporting abstract base classes in Python for comparison. I would love to see a rationale as tailored to Swift and to real problems as PEP 3119 was to Python and its programmers' problems! In Python's case, "[m]uch of the thinking that went into the proposal [was] not about the specific mechanism of ABCs, as contrasted with Interfaces or Generic Functions (GFs), but about clarifying philosophical issues…" This sort of laborious semantic work is a necessary accompaniment to any significant proposed changes to an object system, and that thought is unfortunately not apparent in this proposal.</div><div class=""><br class=""></div><div class=""><br class=""></div><div apple-content-edited="true" class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">--<br class="">Jeremy W. Sherman<br class=""><a href="https://jeremywsherman.com/" class="">https://jeremywsherman.com/</a></div></div></body></html>