<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 Dec 21, 2015, at 11:31 AM, Javier Soto 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="">I think it's just as important for methods. If you make a class final, all methods become final, so that's OK. But if you make a class subclassable, and then forget to mark some of it's methods final, then all methods would be overridable which is probably not what you'd want in must cases. <br class=""></div></blockquote><div><br class=""></div><div>I agree. I am wondering if we should separate the two topics into distinct threads though. As this topic has most recently been focused on classes perhaps we should adjust the subject line and start a new thread focused on methods within classes that <i class="">are not</i> final. </div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Dec 21, 2015 at 9:19 AM Tomáš Linhart <<a href="mailto:tomas@linhart.me" class="">tomas@linhart.me</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="">Hello,</div><div class=""><br class=""></div><div class="">I must say, I am not big fun of this proposal because currently in Swift only way how to mock classes is to subclass them. If this proposal becomes reality, it will make mocking of all third-party libraries impossible unless they mark their classes non-final and I am afraid authors will just use the default behaviour so at the end people will stop testing code that is using third-party libraries or they will have to fork the libraries or ask the authors. This can be fixed by having better testing support in Swift but I don't think, this will happen anytime soon.</div><div class=""><br class=""></div><div class="">I would rather see introduction of better reflection so mock frameworks can be reality. I would like to see also other building block of objected-oriented-programming such as abstract classes, protocols with generic type parameters and not just abstract types (associated types) that allows to design better APIs that don't depend so much on overriding regular classes.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Tomáš</div></font></span></div></div>
</blockquote></div><div dir="ltr" class="">-- <br class=""></div>Javier Soto
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAcpPIIkKHOQCEADLSwCiY9rD0e8CRdS1D5fb9VIGN-2B-2FwqeZwdff-2F7ifVkrVtLFpIKCh1rRBRN1UBgeCqvCilNM80wn1gYnzE14G8dVwuyRJar6ZoO850CZVkhZ-2FaXu1aU2m6IEVkP987iGdWGyoWSmDFpyUKcLK13Ll3d-2FxkAaxs42dUwfwbgzxR64VcOhipHU-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<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>