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

[Joshua Kopin]

## What is your evaluation of the proposal?

I vote -1 on the proposal as submitted. First of all, while I do 
appreciate the effort that went into writing the proposal, having read 
the whole document I still don't understand (i) exactly what problem is 
being solved here and (ii) why abstract classes are the necessary 
solution to those problems. This might just be a function of my lack of 
knowledge, but considering that this proposal is trying to extend the 
language with a significant new concept, I think the burden should be on 
its author to analyze the problem, sketch out a space of possible 
solutions to the problem as analyzed, weight these solutions against one 
another by examining each of their consequences, and demonstrate why the 
proposed solution is the best possible option in light of the 
alternatives.


## If you have used other languages or libraries with a similar feature, 
how do you feel that  this proposal compares to those?

To put my cards on the table -- while I do acknowledge their utility I'm 
not a big fan on abstract classes. I think they're an ad-hoc solution to 
a deep problem that benefits from a more principled approach.

Here's my best attempt at a breakdown. In my view, if classes give 
programmers a concise way to specify a data structure, its interface, 
and its implementation in an open, hierarchically extensible fashion, 
abstract classes give programmers a concise way to *partially* specify a 
data structure, its interface, and its implementation in an open, 
hierarchically extensible fashion.

The issue I have with abstract classes is that there are much better, 
more principled ways to solve the problem of partial specification of an 
data structure / interface implementation in an extensible fashion 
(mixins, in particular, which I understand to be more or less 
protocols-with-storage that introduce a subtyping relationship with 
anything that mixes them in). Abstract classes are a convenient, nearly 
inevitable, and actually pretty decent incremental extension of the 
object-oriented paradigm. But when you break out the deep problems 
abstract classes are meant to solve, they emerge (in my opinion) as 
incomplete, limited, and ultimately unhelpful despite their utility.

The main reason for this is that they lock users into hierarchical 
inheritance (and hierarchical thinking) when it isn't needed, it isn't 
efficient, and it isn't as flexible as it could be. The flexibility 
afforded by mixins (especially if mixins themselves could inherit from 
and extend one another) would allow the user to reuse code in far more 
ways that abstract classes currently do. It would allow functionality to 
be factored out in all of the clever ways protocol extensions currently 
allow but without the storage-related limitations.

## Is the problem being addressed significant enough to warrant a change 
to Swift?

I'm not sure, partially because having read the proposal I'm still not 
clear exactly what the problem is. While I have on occasion missed 
something like abstract classes in Swift, that itch has always been 
minor, and it is often an indication that my architecture could use a 
good rethink. On top of that, as I outlined above, mixins have always 
seemed to me like a strictly more powerful solution to the same problem 
solved by abstract classes. I'd be willing to wait for protocols / 
protocol extensions to gain the ability to add storage to the structs 
and classes that adopt them.

## Does this proposal fit well with the feel and direction of Swift?

I don't think so, for the reasons above.

## How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

I read the whole proposal once and have followed the discussion a little 
bit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160226/479aa5fd/attachment.html>