<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 16 juil. 2016 à 18:05, Jose Cheyo Jimenez 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=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* What is your evaluation of the proposal?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">+1 as before but I do have concerns</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Why do open classes need to have also have open superclasses? </div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* I don’t think sealed methods/properties as default is the right default. </div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* If the default was open for methods/properties, then do we really need the sealed keyword? Could’t we just use final for that?</div><br class=""><blockquote type="cite" class=""><div 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></blockquote><div class=""><br class=""></div><div class="">Yes</div><br class=""><blockquote type="cite" class=""><div 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></blockquote><div class=""><br class=""></div><div class="">Requiring super classes to also be Open seems wrong. </div></div></div></div></blockquote></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=""><div class=""><br class=""></div><div class="">I agree with Kevin Ballard on being open by default for methods/ properties <a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/" class="">http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/</a></div><div class=""><br class=""></div><div class="">If we are open by default for methods/properties then we could simplify things by just using final for methods that need to be sealed; I don’t see the need to have sealed methods/properties outside of the module ONLY. </div><div class=""><br class=""></div><div class="">We already have to mark all public methods/properties as public, if I need something not the be overridable then I can just use final. This would work the same across all classes. </div><div class=""><br class=""></div><div class="">If I was a framework author that initially just had a library that was sealed but then somebody asked me to make it open; All I would want to do is add open to the class only, I would not want to spend the time to go back an add open to all public methods/properties specially if I am already using final. I think having method/properties open by default is the best compromised. I can see framework authors switching a class to be open and expecting that everything in the class in open and if they don’t open any methods, then what possible use is a subclass than an extension could not provide? </div></div></div></div></blockquote><div><br class=""></div><div>Extensions do not support stored properties (yet?). Subclasses do. That said, I agree that having an open class without any open member does not has much benefit, but I’m sure we can find a valid use case for such class.</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=""><div class="">I think that is an overreach to make the framework author have to add open to every public method in addition to having to open every super class. As a framework author if I think my clients could use subclassing, all I want to do is flip a switch on the classes that I want to make subclass able and then just push a new version. As a framework user I want to be able to tell my framework author “can you just add open to classes abs and deca etc.” I think it is more likely that I will get my request if it is easy vs it the framework author needs to touch every class in the hierarchy. </div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div 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></blockquote>n/a<br class=""><blockquote type="cite" class=""><div 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?<br class=""></div></div></blockquote><br class=""></div><div class="">reviewed previously and followed the update. </div><br class=""></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>