<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="">Le 26 févr. 2016 à 23:21, David Scrève via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</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=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class=""></pre><span class="Apple-tab-span" style="white-space:pre"> </span>Actually, protocols and extensions cannot handle methods that requires attributes and data storage.<div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>So, by design, protocols and extensions can only be used to implement stateless interface where abstract classes are true classes with a state supported with attributes and properties.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Abstract class can also enforce methods to be implemented and avoid misuse of default method implementation.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>For example, NSOperation is a good candidat to abstract class because NSOperation itself is useless as a standalone class and should not be used as-it. -(void)main should be made abstract because I don’t think NSOperation does not have any internal property and has default behavior.</div></div></div></blockquote><div><br class=""></div><div>IMHO, NSOperation could be better design using closure. Abstract class is probably a concept that fit well with API that where design with it in mind, but it does not mean it is needed in Swift.</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="">David</div><div class=""><div class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">I am against the proposal. I believe that protocols, mix-ins and composition are better answers to the problems that abstract classes are usually called to solve. In my experience, abstract classes lead to subpar design decisions.
><i class=""> • Is the problem being addressed significant enough to warrant a change to Swift?
</i>
I do not believe so. There are most likely cases where current tools could be improved, by that should be done by improving support for behavior composition rather than forced subclassing
><i class=""> • Does this proposal fit well with the feel and direction of Swift?
</i>
I do not believe so, for the reason outlined above
><i class=""> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
</i>><i class=""> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
</i>
A quick glance.
><i class=""> On 26 Feb 2016, at 19:11, Joe Groff via swift-evolution <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">swift-evolution at swift.org</a>> wrote:
</i>><i class="">
</i>><i class=""> Hello Swift community,
</i>><i class="">
</i>><i class=""> The review of “Abstract classes and methods” begins now and runs through March 4, 2016. The proposal is available here:
</i>><i class="">
</i>><i 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> <<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>>
</i>><i class=""> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
</i>><i class="">
</i>><i class=""> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>>
</i>><i class=""> or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
</i>><i class="">
</i>><i class=""> Proposal link:
</i>><i class="">
</i>><i 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> <<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>>
</i>><i class=""> Reply text
</i>><i class="">
</i>><i class=""> Other replies
</i>><i class="">
</i>><i class=""> What goes into a review?
</i>><i class="">
</i>><i class=""> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
</i>><i class="">
</i>><i class=""> • What is your evaluation of the proposal?
</i>><i class=""> • Is the problem being addressed significant enough to warrant a change to Swift?
</i>><i class=""> • Does this proposal fit well with the feel and direction of Swift?
</i>><i class=""> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
</i>><i class=""> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
</i>><i class="">
</i>><i class=""> More information about the Swift evolution process is available at:
</i>><i class="">
</i>><i class=""> <a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a> <<a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a>>
</i>><i class=""> Thank you,
</i>><i class="">
</i>><i class=""> -Joe
</i>><i class=""> Review Manager
</i>><i class=""> _______________________________________________
</i>><i class=""> swift-evolution mailing list
</i>><i class=""> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">swift-evolution at swift.org</a>
</i>><i class=""> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></i></pre></blockquote><div class=""><br class=""></div></div></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=""></body></html>