<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="">My thoughts exactly! I don’t not understand the following statement:<div class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">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></div></blockquote><div class=""><br class=""></div>My argument is that declaring to be the subclass of an abstract class, or declaring to be in conformance with a protocol would have the same effect. Even the syntax would be the same, e.g. </div><div class=""><br class=""></div><div class="">class ConcreteClass: AbstractSuperclass { … }</div><div class=""><br class=""></div><div class="">or </div><div class=""><br class=""></div><div class="">class ConcreteClass: ProtocolWithoutExtensions { … }</div></div><div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class="Apple-tab-span" style="white-space: pre;"><br class="Apple-interchange-newline"> </span>Coleman,</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Mar 3, 2016, at 4:21 PM, Matthew Judge <<a href="mailto:matthew.judge@gmail.com" class="">matthew.judge@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Not necessarily commenting for or against abstract classes, but the following logic confuses me:</div><div class=""><br class=""></div><div class=""><div class="">"ONLY an abstract class, ON ITS OWN, can force concrete subclassers to provide an implementation for a given thing.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Mar 3, 2016 at 3:39 PM, Evan Maloney via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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;" class=""><div class=""><span class=""><blockquote type="cite" class=""><span style="font-family:"Helvetica Neue"" class="">- What is your evaluation of the proposal?</span><br class=""></blockquote><div class=""><br class=""></div></span><div class="">I could not more strongly support the proposal to add abstract classes, functions and properties to Swift.</div><div class=""><br class=""></div><div class="">None of the proposals involving protocols as a solution to this have addressed the fundamental issue:</div><div class=""><br class=""></div><div class="">*ONLY* abstract classes ON THEIR OWN allow the compiler to enforce providing an implementation for a given function.</div><div class=""><br class=""></div><div class="">For example -- and not picking against the author of this, it's just the most recent example to grace my inbox:</div><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div style="-ms-word-wrap: break-word;" class=""><div class=""><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px" class="">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 class=""><br class=""></div></span><div class="">This does not address the fundamental concern of abstract classes.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">ONLY an abstract class, ON ITS OWN, can force concrete subclassers to provide an implementation for a given thing.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Abstract classes enforce a requirement that a given portion of the class hierarchy provide an implementation of X.</div><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div style="-ms-word-wrap: break-word;" class=""><div class=""><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px" class="">• Is the problem being addressed significant enough to warrant a change to Swift?</div></div></div></blockquote><div class=""><br class=""></div></span>Yes.</div><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div style="-ms-word-wrap: break-word;" class=""><div class=""><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px" class="">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 class=""><br class=""></div></span>No, protocols *do not implement* this functionality. They provide something else, and are orthogonal to the class hierarchy.</div><div class=""><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div style="-ms-word-wrap: break-word;" class=""><div class=""><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px" class="">• Does this proposal fit well with the feel and direction of Swift?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""><blockquote type="cite" class=""><div style="-ms-word-wrap: break-word;" class=""><div class=""><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px" class="">No. It goes against protocol oriented programming.</div></div></div></blockquote><div class=""><br class=""></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 class=""><span class=""><br class=""><blockquote type="cite" class=""><div style="-ms-word-wrap: break-word;" class=""><div class=""><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px" class=""> 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 class=""><br class=""></div></span><div class="">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 class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div style="-ms-word-wrap: break-word;" class=""><div class=""><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px" class="">• 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 class=""><br class=""></div></span><div class="">C++ and have found them EXTREMELY useful. This proposal is in line with that.</div><span class=""><br class=""><blockquote type="cite" class=""><div style="-ms-word-wrap: break-word;" class=""><div class=""><div style="margin:0px;line-height:normal;font-family:"Helvetica Neue";font-size:14px" class="">• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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 class=""><br class=""></div><div class=""><a href="https://gist.github.com/emaloney/d0b5bf7dd831d4f7415c" target="_blank" class="">https://gist.github.com/emaloney/d0b5bf7dd831d4f7415c</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" rel="noreferrer" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>