[swift-evolution] [Review] SE-0026 Abstract classes and methods

[Jeremy W. Sherman]

> El 26 feb 2016, a las 13:11, Joe Groff via swift-evolution <swift-evolution at swift.org> escribió:

This is a review of [SE-0026 "Abstract classes and methods".](https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md) <https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md>

I am **against** the acceptance of this proposal:

- It lacks a clear problem.
- The leap from a nebulous problem to abstract classes as the solution is a *non sequitur.*
- 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.

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.


## No Clear Problem
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.

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 `url` as a constructor argument, as [noted by Stephen Celis.](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011207.html) <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011207.html> Further, the immediate solution appears to be to argue in favor of [uniform access](https://en.wikipedia.org/wiki/Uniform_access_principle) <https://en.wikipedia.org/wiki/Uniform_access_principle> as found in Self and Eiffel, not abstract base classes, which compound non-uniform access by a further serving of complexity.

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. `NSProxy` has always been somewhat awkward in this regard; perhaps we can do better in Swift?


## No Clear Significance
Without a clear problem to address, it becomes difficult to evaluate the significance of the problem.

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.

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.


## Compared to Python's Rationale for Adding Abstract Classes
It is interesting to consider the motivation for adding abstract base class support to Python as explained in [PEP 3119](https://www.python.org/dev/peps/pep-3119/). <https://www.python.org/dev/peps/pep-3119/>

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 (["Rationale"](https://www.python.org/dev/peps/pep-3119/#rationale) <https://www.python.org/dev/peps/pep-3119/#rationale>).

As a result, Python adopted abstract base classes as an alternative to interfaces (["ABCs vs. Interfaces"](https://www.python.org/dev/peps/pep-3119/#abcs-vs-interfaces) <https://www.python.org/dev/peps/pep-3119/#abcs-vs-interfaces>). But Swift already has interfaces in the form of protocols; this answers the need that motivated the addition of abstract base classes to Swift.

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.


# Out of Alignment with Swift
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.


# Effort
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.


--
Jeremy W. Sherman
https://jeremywsherman.com/ <https://jeremywsherman.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160228/4bbacf9b/attachment.html>