<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">-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.<div class=""><br class=""></div><div class="">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.<br class=""><div class=""><br class=""></div><div class="">Matt</div><div class=""> <br class=""><div><blockquote type="cite" class=""><div class="">On Feb 26, 2016, at 11:58, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span style="white-space:pre-wrap" class=""> </span>• What is your evaluation of the proposal?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I am in favor of this proposal, for reasons described below.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>• Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">In my opinion, yes.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>• Does this proposal fit well with the feel and direction of Swift?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.)</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">n/a, although the design seems like a thoroughly conventional one compared to the same concept in other OO languages.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Close reading of proposal document. Following (and posted in) various threads in which the topic came up.</div></div><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>