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

[Matt Whiteside]

-1.  I don’t think the protocol oriented programming has had enough time to sink in yet, and I’d like to see what else can be done with protocols as the generic system matures.  Then maybe revisit this topic next year and see if abstract classes are still as desirable.

Others on this thread have suggested workarounds to accomplish the job of abstract classes, and I’m happy to do that for the time being rather than changing the language.

Matt
 
> On Feb 26, 2016, at 11:58, 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/f9bafd2f/attachment.html>