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

[Austin Zheng]

>
> • What is your evaluation of the proposal?
>

I am in favor of this proposal, for reasons described below.


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

In my opinion, yes.

Currently (and for some time to come to come), one of Swift's primary use
cases will be building iOS and OS X applications using the Cocoa and Cocoa
Touch frameworks. These frameworks are object-oriented and
inheritance-based. They make use of the class cluster pattern and contain
classes that are meant only as templates for application subclasses.
Support for abstract classes would allow formalizing usage restrictions
that currently exist only as informal conventions, sternly worded
documentation comments, and runtime asserts.

Even if Cocoa is never augmented to take advantage of abstract Swift
classes (an idea: pragma directive to import an Objective-C class as
'abstract'?), there are quite a few app development patterns which involve
creating 'abstract' view controllers or UI elements with various
customization points meant to be filled in by subclasses. Abstract class
support would make this less error-prone.


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

The question we should be asking is, "is inheritance-based object-oriented
programming using `class` a first-class Swift citizen?" Or is Swift's OO
subsystem something 'grudgingly' included in the language to facilitate
ObjC/Cocoa interop? I love POP and hate the misuse of inheritance as much
as anyone on this list, but I still think that inheritance-based modeling
is the best solution to at least some types of problems.

I don't think abstract classes unduly burden the rest of the language, and
I think they are an important part of object-oriented programming and
interop with existing frameworks that Objective-C could have benefitted
from. ('Burden' in this case is in contrast to something like inout, an
excellent feature which nonetheless has resulted in weird ramifications for
everything from tuple splatting to closure argument capture to currying.)


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

n/a, although the design seems like a thoroughly conventional one compared
to the same concept in other OO languages.


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

Close reading of proposal document. Following (and posted in) various
threads in which the topic came up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160226/f32e79ff/attachment.html>