<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 26, 2016, at 12:11 PM, Joe Groff 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">Proposal link:</blockquote><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md</a></blockquote></blockquote><br class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• What is your evaluation of the proposal?<br class=""></div></div></div></blockquote><div><br class=""></div><div>A tentative -1; although there are places abstract classes *would* be useful, I can’t think of a single such scenario for which an abstract class would be the *best* solution (or at least the solution I’d prefer).</div><div><br class=""></div><div>Since the points I would make here have already been made I won’t belabor this point; suffice to say it’d be a lot more compelling a proposition if there were an example usage that fundamentally required the abstract-class approach (and couldn’t simply accept some parameters in `init`).</div><div><br class=""></div><div>I do have some “fresh" concerns, however.</div><div><br class=""></div><div># Support For “Intermediate” Classes</div><div><br class=""></div><div>As stated, it seems the proposal would force classes to be either or concrete; this is going to be limiting at times, and approaches like the below are often useful:</div><div><br class=""></div><div>// fully-abstract</div><div>abstract class BaseClass {</div><div> </div><div> abstract func someFunction()</div><div><div> abstract func someOtherFunction()</div><div class=""><br class=""></div></div><div>}</div><div><br class=""></div><div>// partially-abstract</div><div>abstract class IntermediateClass : BaseClass {</div><div><br class=""></div><div> override func someFunction() { /* implementation here */ }</div><div><br class=""></div><div>}</div><div><br class=""></div><div>// fully-concrete</div><div>class TerminalClass : IntermediateClass {</div><div><br class=""></div><div> override func someOtherFunction() { /* implementation here */ }</div><div><br class=""></div><div>}</div><div><br class=""></div><div>…although I could be mis-reading the proposal.</div><div><br class=""></div><div># Access Control Issues: Mixed OK, or Not?</div><div><br class=""></div><div>Abstract classes and access control issues would need to be addressed. EG: is the below allowed, or not:</div><div><br class=""></div><div>abstract public class ClassWithInternalAbstractMembers {</div><div><br class=""></div><div> // abstract members less visible than the containing type:</div><div> internal abstract func someFunctionOnlyVisibleWithinThisModule()</div><div> private abstract func someFunctionOnlyVisibleWithinThisFile()</div><div><br class=""></div><div>}</div><div><br class=""></div><div>…?</div><div><br class=""></div><div>I think *not* is more consistent with how Swift generally works, but if *not* is chosen it has some awkward implications for how useful the feature is (see next point).</div><div><br class=""></div><div># Can’t Use Nicely For a “Closed" Class-Cluster</div><div><br class=""></div><div>I personally think the strongest case for abstract classes is as an aide to building class-clusters, but there seem to be major issues doing this from Swift, especially if you are hoping for a “closed” class-cluster (e.g. one that isn’t meant for subclassing "from outside the module”). That is, it should meet the following bullet-points:</div><div><br class=""></div><div>- there’s an abstract public base class (as the public-API)</div><div><div>- this public base class is de-facto final (not meant for “external” subclassing)</div><div>- there are some “private”, concrete subclasses (specialized in various ways, and all `final`)</div><div><br class=""></div><div>…(noting that you wouldn’t always *want* a closed cluster, but sometimes you would…). </div><div><br class=""></div><div>One annoying issue here is that such a class-cluster can’t use `init`; even if we *could* have `init` return a subclass instance, the compiler would still presumably want to prevent us from “instantiating” an instance of our abstract class, and this seems awkward to really resolve…so we’re stuck with static factory functions (which will seem unnatural).</div><div><br class=""></div><div>Most of the other issues I’d raise re really due to the lack of a way to say “this class/this method/etc. should be *treated* as final outside this module, even if it’s not actually `final` within the module”. But, without that kind of feature, it becomes hard to achieve a “de-facto `final`” approach, b/c:</div><div><br class=""></div><div>- the abstract base class is public</div><div>- thus the abstract functions are also public (by no-mixed-visibility assumption)</div><div>- those methods can’t be marked final (we *need* to override them)</div><div>- thus we can’t achieve the closed-family (b/c the abstract methods are all public and non-final on a public and non-final class)</div><div><br class=""></div><div>…which can be worked around if you keep all the *classes* module-internal and export, say, a public struct wrapper privately wrapping a class instance, but that’s getting pretty unwieldy and feels like it shouldn’t be necessary.</div><div><br class=""></div></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div></div></div></blockquote><div><br class=""></div><div>I think it *exposes* a significant problem, but I’m not sure the fix is right.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Does this proposal fit well with the feel and direction of Swift?<br class=""></div></div></div></blockquote><div><br class=""></div><div>It seems hard to fit into the rest of Swift in the details (e.g. the `init` issue, and the apparent lack of a satisfying way for the implementer to achieve a reasonable balance of visibility, overridability, and finality). </div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </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></div></blockquote><div><br class=""></div><div>It seems broadly similar. </div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div></div></div></blockquote></div><br class=""><div class="">Some thought, some observation of the discussion.</div><div class=""><br class=""></div></body></html>