[swift-evolution] [Review] SE-0026 Abstract classes and methods
jkopin at apple.com
Fri Feb 26 15:28:19 CST 2016
## 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
## 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution