<div dir="ltr">Hello to all of the community.<div><div><br></div><div class="gmail_extra"><div class="gmail_extra"><i> * What is your evaluation of the proposal?</i></div><div class="gmail_extra">+0.5 </div><div class="gmail_extra">Agree on the motivation and 'public open class'</div><div class="gmail_extra">Let's discuss 'public open func' + application to dynamic runtime</div><div class="gmail_extra"><i><br></i></div><div class="gmail_extra"><i> * Is the problem being addressed significant enough to warrant a change to Swift?<br></i></div><div class="gmail_extra"><i> * Does this proposal fit well with the feel and direction of Swift?</i></div><div class="gmail_extra"><i> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</i></div><div class="gmail_extra"><br></div><div class="gmail_extra">My perspective is as follows. </div><div class="gmail_extra"><br></div><div class="gmail_extra">We are designing a language that has a concept of classes and overrides. Let's create a class and put some functions into it with the default modifiers. </div><div class="gmail_extra"><br></div><div class="gmail_extra"><b>Should it be possible to override those functions in the other parts of the code?</b></div><div class="gmail_extra"><br></div><div class="gmail_extra">This is a deep question of language design. An answer will have profound ramifications regarding the code that the compiler is allowed to produce. It's not surprising that different languages give different answers:<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">- Java and Objective-C say "Yes"</div><div class="gmail_extra">- C++ and C# say "No"</div><div><br></div><div>Now, it doesn't look to me like it's "impossible to use libraries" in those last two languages or that one has "less fun", or that they are "disadvantaged on the server" because of their design choices. </div><div class="gmail_extra"><br></div><div class="gmail_extra">What it looks like is a tradeoff. A freedom in one place is a requirement in another place – if you say "one should be able to override those methods", it means "a compiler should be required to perform virtual dispatch on any call to those methods". <br></div><div class="gmail_extra"><br></div><div class="gmail_extra">A smart compiler will be able to perform some guaranteed optimizations if it knows that the calls can be devirtualized. This is a good thing, because you can perfrom refactoring "for free".</div><div class="gmail_extra"><br></div><div class="gmail_extra">As an example, in the scenario below Pyramid.computeVolume() can be devirtualized even if you refactor this class as a subclass of an abstract "Geometric-Body" class and make computeBase() overrideable.</div><div class="gmail_extra"><br></div><div class="gmail_extra"> class Pyramid {<br></div><div class="gmail_extra"> func computeVolume() { return computeBase() * height / 3}</div><div class="gmail_extra"> func computeBase() { return π * radius * radius }</div><div class="gmail_extra"> }</div><div class="gmail_extra"><br></div><div class="gmail_extra">This ability to extract away the code without the performance penalty and without turning it into an unwanted override point is a benefit of the "No" answer to the aforementioned question.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The ability to quickly design a hierarchy of classes without worrying first about making them virtual is a benefit of the "Yes" answer to the aforementioned question.</div><div class="gmail_extra"><br></div><div class="gmail_extra">What would a good tradeoff then look like? It would combine the advantages of both approaches. I believe that a default "Yes" answer within a module and "No" across the boundary does that.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Therefore I feel like this proposal moves Swift in the right direction.</div><div class="gmail_extra"><br></div><div class="gmail_extra">However, I'm not sure that 'open' is the right keyword for functions and would prefer to see more discussion regarding it. </div><div class="gmail_extra"><br></div><div class="gmail_extra">It's less clear what the benefits of non-open classes are in the dynamic runtime, as we can't really promise that they will not be subclassed. Incidentally, a lot of the criticism of the proposal touches the usage in Swift of Cocoa Touch APIs. Maybe there is value in leaving things exactly as they currently are in the Objective-C.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><i> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</i></div><div><br></div><div>This is the first proposal I feel compelled to respond to. </div><div><br></div><div>Many interesting points regarding the proposal have been raised. I've spent some time trying to read most of the thread and thought about this question during a day. I also refreshed my memory regarding other languages, and the design patterns of inheritance in general, e.g. here:</div><div><br></div><div>- <a href="https://codeblog.jonskeet.uk/2006/03/04/inheritancetax/">https://codeblog.jonskeet.uk/2006/03/04/inheritancetax/</a></div><div>- <a href="http://blog.berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/">http://blog.berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/</a></div><div>- <a href="http://www.artima.com/intv/nonvirtualP.html">http://www.artima.com/intv/nonvirtualP.html</a> </div><div>- <a href="http://stackoverflow.com/a/14451437/115200">http://stackoverflow.com/a/14451437/115200</a> (Eric Lippert)</div><div> </div><div>Thank you if you got up to here, </div><div>Ilya.</div><div><br></div><div class="gmail_quote">On Sat, Jul 16, 2016 at 7:52 AM, Chris Lattner 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello Swift community,<br>
<br>
The second review of "SE-0117: Default classes to be non-subclassable publicly" begins now and runs through July 22. The proposal is available here:<br>
<br>
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md</a><br>
<br>
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br>
<br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
or, if you would like to keep your feedback private, directly to the review manager.<br>
<br>
What goes into a review?<br>
<br>
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:<br>
<br>
* What is your evaluation of the proposal?<br>
* Is the problem being addressed significant enough to warrant a change to Swift?<br>
* Does this proposal fit well with the feel and direction of Swift?<br>
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
<br>
More information about the Swift evolution process is available at<br>
<br>
<a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
<br>
Thank you,<br>
<br>
-Chris Lattner<br>
Review Manager<br>
<div class=""><div class="h5"><br>
<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div></div>