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

[Shawn Erickson]

I am on the road at the moment so hard to do a full reply to the
proposal... so I just want to say basically ditto to what Austin posted.

It improve class support in Swift while not getting in the way of other
Swift paradigms.

On Fri, Feb 26, 2016 at 11:58 AM Austin Zheng via swift-evolution <
swift-evolution at swift.org> wrote:

> • 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.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160226/3f5d88b0/attachment.html>