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