<div dir="ltr"><div>Not necessarily commenting for or against abstract classes, but the following logic confuses me:</div><div><br></div><div><div>"ONLY an abstract class, ON ITS OWN, can force concrete subclassers to provide an implementation for a given thing.</div><div><br></div><div>Protocols can't do this, because if you forget to declare conformance with the protocol, the compiler can't enforce anything. This pushes what could be caught at compile-time to a runtime (potentially crashing) problem."</div><div><br></div><div>What is the difference between forgetting to declare conformance to a protocol and forgetting to subclass an abstract class? An abstract class, ON ITS OWN, cannot force a class to do anything unless that class declares itself a subclass of the abstract class.</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 3, 2016 at 3:39 PM, Evan Maloney via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="-ms-word-wrap: break-word;"><div><span><blockquote type="cite"><span style="font-family:"Helvetica Neue"">- What is your evaluation of the proposal?</span><br></blockquote><div><br></div></span><div>I could not more strongly support the proposal to add abstract classes, functions and properties to Swift.</div><div><br></div><div>None of the proposals involving protocols as a solution to this have addressed the fundamental issue:</div><div><br></div><div>*ONLY* abstract classes ON THEIR OWN allow the compiler to enforce providing an implementation for a given function.</div><div><br></div><div>For example -- and not picking against the author of this, it's just the most recent example to grace my inbox:</div><span><div><br></div><blockquote type="cite"><div style="-ms-word-wrap: break-word;"><div><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px">I am against the proposal because I feel it goes against the Protocol Oriented Programming patterns found in the Swift Standard Library. Current protocol functionality can provide a solution for the given example. If a protocol property is not implemented, the compiler will not let you compile. </div></div></div></blockquote><div><br></div></span><div>This does not address the fundamental concern of abstract classes.</div><div><br></div><div>Yes, a protocol will force you to provide an implementation. However, a protocol *by itself* cannot force the implementor of a class to provide an implementation unless that class declares itself in conformance with that protocol.</div><div><br></div><div>ONLY an abstract class, ON ITS OWN, can force concrete subclassers to provide an implementation for a given thing.</div><div><br></div><div>Protocols can't do this, because if you forget to declare conformance with the protocol, the compiler can't enforce anything. This pushes what could be caught at compile-time to a runtime (potentially crashing) problem.</div><div><br></div><div>Abstract classes enforce a requirement that a given portion of the class hierarchy provide an implementation of X.</div><span><div><br></div><blockquote type="cite"><div style="-ms-word-wrap: break-word;"><div><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px">• Is the problem being addressed significant enough to warrant a change to Swift?</div></div></div></blockquote><div><br></div></span>Yes.</div><div><span><br><blockquote type="cite"><div style="-ms-word-wrap: break-word;"><div><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px">No, protocols implement this functionality, but with a different syntax. There is no lacking or additional functionality this proposal provides.</div></div></div></blockquote><div><br></div></span>No, protocols *do not implement* this functionality. They provide something else, and are orthogonal to the class hierarchy.</div><div><span><div><br></div><blockquote type="cite"><div style="-ms-word-wrap: break-word;"><div><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px">• Does this proposal fit well with the feel and direction of Swift?</div></div></div></blockquote><div><br></div></span><div>Absolutely. Swift is about safety, about letting the compiler perform safety checks. ONLY abstract classes allow the compiler to enforce that an implementor of a given subclass has provided an implementation for a given function.</div><div><br></div><div>Solutions that require the use of protocols can only be checked for correctness if the implementor of the subclass in question ALSO declares conformance to the protocol.</div><div><br></div><div>In other words, a protocol-based solution can only be checked by the compiler if the developer does 2 things correctly (declares protocol conformance and provides an implementation), whereas abstract classes allow the compiler to perform checks as long as the developer does 1 thing (subclass a given class).</div><span><br><blockquote type="cite"><div style="-ms-word-wrap: break-word;"><div><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px">No. It goes against protocol oriented programming.</div></div></div></blockquote><div><br></div></span>Swift isn't ONLY about protocol oriented programming. Classes are here for a reason, and they should not be relegated to second-class status where people refuse to consider class-only functionality just because the concept can't be shoehorned into something protocol-related.</div><div><span><br><blockquote type="cite"><div style="-ms-word-wrap: break-word;"><div><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px"> Furthermore, this is only for classes, structs are being excluded in this case. I feel that with most of the standard library being implemented as structs, this is not acceptable.</div></div></div></blockquote><div><br></div></span><div>Rather than reject this proposal because "this is only for classes," perhaps recognize that this is only for classes PRECISELY because this type of problem--the one that abstract classes addresses--only occurs with a class hierarchy.</div><span><div><br></div><blockquote type="cite"><div style="-ms-word-wrap: break-word;"><div><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px">• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</div></div></div></blockquote><div><br></div></span><div>C++ and have found them EXTREMELY useful. This proposal is in line with that.</div><span><br><blockquote type="cite"><div style="-ms-word-wrap: break-word;"><div><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px">• 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></div></span><div>I've been following this discussion very closely, and before I realized there was already a proposal in the queue for abstract classes, I also wrote a similar proposal:</div><div><br></div><div><a href="https://gist.github.com/emaloney/d0b5bf7dd831d4f7415c" target="_blank">https://gist.github.com/emaloney/d0b5bf7dd831d4f7415c</a></div><div><br></div><div><br></div><div><br></div></div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" rel="noreferrer">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>