<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I disagree that a stable for over 30 years of every OOP language that I know is equivalent to lack of care for good library design, but if we want to push value types by making working with classes harder so be it :P. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Seriously though</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">Mine is the opinion of a library-maker,<br>yours of the user of poorly designed/developed libraries.</span></font></blockquote><div id="AppleMailSignature"><br></div>this kind of attitude on this list got to stop.<br><br>Sent from my iPhone</div><div><br>On 7 Jul 2016, at 17:23, Leonardo Pessoa via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Jean, IMO marking every class as subclassable means the creator does</span><br><span>not care for you to design and develop a great library because s/he is</span><br><span>not caring for the library at all. I right now have to go through the</span><br><span>burdensome activity of marking too many classes/methods as final to</span><br><span>prevent misuse of my libraries and find good design workarounds when I</span><br><span>need to subclass internally what I don't want you to subclass.</span><br><span></span><br><span>IMO the usage of a library is to be crafted/planned/designed by their</span><br><span>developers not their users. Mine is the opinion of a library-maker,</span><br><span>yours of the user of poorly designed/developed libraries. By pushing</span><br><span>this proposal, developer of such libraries will have much burden to</span><br><span>make/keep a poor library or will have to work on better</span><br><span>design/implementation for it to suit its purpose.</span><br><span></span><br><span>L</span><br><span></span><br><span>On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution</span><br><span><<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br><blockquote type="cite"><span> * What is your evaluation of the proposal?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Strong -1 too.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I can’t count the number of times it save my hours tone able to override</span><br></blockquote><blockquote type="cite"><span>arbitrary classes and methods.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Sometimes to simply add log point to understand how the API work. Other</span><br></blockquote><blockquote type="cite"><span>times to workaround bugs in the library. Or even to extends the library in a</span><br></blockquote><blockquote type="cite"><span>way that the author did not intent in the first place, but that was</span><br></blockquote><blockquote type="cite"><span>perfectly supported anyway.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I already see how libraries author will react to that new default. They will</span><br></blockquote><blockquote type="cite"><span>either don’t care and mark all classes as subclassable, or find to</span><br></blockquote><blockquote type="cite"><span>burdensome to get subclassability right and prohibit subclassing all</span><br></blockquote><blockquote type="cite"><span>classes.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution</span><br></blockquote><blockquote type="cite"><span><<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>* What is your evaluation of the proposal?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>A **strong** -1</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>First, I have often found that you can’t always predict the way which</span><br></blockquote><blockquote type="cite"><span>something will need to be extended. You think you know, but are then</span><br></blockquote><blockquote type="cite"><span>surprised by creative uses. My favorite features of Swift/Cocoa involve</span><br></blockquote><blockquote type="cite"><span>retroactive modeling.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Second, I don’t think this proposal will achieve its stated objective of</span><br></blockquote><blockquote type="cite"><span>forcing people to think about subclassing more. It will just add confusing</span><br></blockquote><blockquote type="cite"><span>boilerplate.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Things like Swift optionals work well because they make the (often</span><br></blockquote><blockquote type="cite"><span>forgotten) choices explicit in the context that they are used. In the world</span><br></blockquote><blockquote type="cite"><span>of Human Factors, we call it a forcing function. This proposal has the</span><br></blockquote><blockquote type="cite"><span>inverse structure, and will be ineffective, because the “forcing” part of it</span><br></blockquote><blockquote type="cite"><span>shows up in a different context (i.e. trying to use a framework) than the</span><br></blockquote><blockquote type="cite"><span>decision is being made in (writing the framework). This type of thinking</span><br></blockquote><blockquote type="cite"><span>leads to things like Java and the DMV.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>As Tino said:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>No matter what the defaults are, good libraries are hard to build, so I</span><br></blockquote><blockquote type="cite"><span>predict this proposal would not only fail in increasing framework quality,</span><br></blockquote><blockquote type="cite"><span>but also will make it much harder for users of those frameworks to work</span><br></blockquote><blockquote type="cite"><span>around their flaws, which are just a natural part of every software.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I think he is right on here. Those who were prone to be thoughtful about</span><br></blockquote><blockquote type="cite"><span>their design would have been anyway. Those who are not thoughtful about</span><br></blockquote><blockquote type="cite"><span>their design will just leave these annotations off… leaving us with no</span><br></blockquote><blockquote type="cite"><span>recourse to extend/modify classes. When people complain, they will add the</span><br></blockquote><blockquote type="cite"><span>annotations without actually thinking about the meaning (i.e. stack overflow</span><br></blockquote><blockquote type="cite"><span>/ the fixit tells me I need to add this word to make the compiler happy).</span><br></blockquote><blockquote type="cite"><span>All this does is put framework users at the mercy of the framework writers.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Finally, this proposal is missing important aspects of the problem space.</span><br></blockquote><blockquote type="cite"><span>If we truly want to solve the issue of subclassing, we need to consider all</span><br></blockquote><blockquote type="cite"><span>of the common issues which arise. Looking at the cocoa documentation you</span><br></blockquote><blockquote type="cite"><span>will see several types of annotations:</span><br></blockquote><blockquote type="cite"><span>1) This method MUST be overridden</span><br></blockquote><blockquote type="cite"><span>2) This method should NOT be overridden</span><br></blockquote><blockquote type="cite"><span>3) This method MUST be called</span><br></blockquote><blockquote type="cite"><span>3) This method should NOT be called except by subclasses</span><br></blockquote><blockquote type="cite"><span>4) This method should NOT be called except by a method override calling</span><br></blockquote><blockquote type="cite"><span>super</span><br></blockquote><blockquote type="cite"><span>5) This method MUST call super</span><br></blockquote><blockquote type="cite"><span>6) Overrides of this method should NOT call super</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>If we are attempting to bring thoughtfulness to the design of classes, I</span><br></blockquote><blockquote type="cite"><span>would like to see things be extendable by default, but with annotations that</span><br></blockquote><blockquote type="cite"><span>thoughtful framework designers can use to designate how a particular method</span><br></blockquote><blockquote type="cite"><span>should be used. In most cases, it should not explicitly forbid the end user</span><br></blockquote><blockquote type="cite"><span>from subclassing, but require them to acknowledge that what they are doing</span><br></blockquote><blockquote type="cite"><span>is not intended by the framework. (e.g. "unsafe override func"…). That</span><br></blockquote><blockquote type="cite"><span>would feel 1000x more swifty to me. Opt-out safety.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>* Is the problem being addressed significant enough to warrant a change to</span><br></blockquote><blockquote type="cite"><span>Swift?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>No. It doesn’t actually solve the problem... and I haven’t actually run into</span><br></blockquote><blockquote type="cite"><span>this problem in the real world.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>* Does this proposal fit well with the feel and direction of Swift?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>No, it gives Swift more of a feeling of busywork and unnecessary boilerplate</span><br></blockquote><blockquote type="cite"><span>while failing to achieve its objective. It goes against the retroactive</span><br></blockquote><blockquote type="cite"><span>modeling allowed by other areas of Swift.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>* If you have used other languages or libraries with a similar feature, how</span><br></blockquote><blockquote type="cite"><span>do you feel that this proposal compares to those?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I tend to avoid languages which require this sort of thing. In other</span><br></blockquote><blockquote type="cite"><span>languages that lock things down, there is a need to unlock things soon after</span><br></blockquote><blockquote type="cite"><span>(e.g. friend classes).</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I predict the same thing will happen here. People will quickly be asking</span><br></blockquote><blockquote type="cite"><span>for the ability to patch/override in cases where the framework designer was</span><br></blockquote><blockquote type="cite"><span>wrong. That shows a problem inherent with the design...</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>* How much effort did you put into your review? A glance, a quick reading,</span><br></blockquote><blockquote type="cite"><span>or an in-depth study?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Read the proposal & discussion. Read earlier discussions around access</span><br></blockquote><blockquote type="cite"><span>control that touched on this subject as well. I have been designing</span><br></blockquote><blockquote type="cite"><span>frameworks for years.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Thanks,</span><br></blockquote><blockquote type="cite"><span>Jon</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Hello Swift community,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The review of "SE-0117: Default classes to be non-subclassable publicly"</span><br></blockquote><blockquote type="cite"><span>begins now and runs through July 11. The proposal is available here:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md">https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Reviews are an important part of the Swift evolution process. All reviews</span><br></blockquote><blockquote type="cite"><span>should be sent to the swift-evolution mailing list at</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>or, if you would like to keep your feedback private, directly to the review</span><br></blockquote><blockquote type="cite"><span>manager.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>What goes into a review?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The goal of the review process is to improve the proposal under review</span><br></blockquote><blockquote type="cite"><span>through constructive criticism and contribute to the direction of Swift.</span><br></blockquote><blockquote type="cite"><span>When writing your review, here are some questions you might want to answer</span><br></blockquote><blockquote type="cite"><span>in your review:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> * What is your evaluation of the proposal?</span><br></blockquote><blockquote type="cite"><span> * Is the problem being addressed significant enough to warrant a change to</span><br></blockquote><blockquote type="cite"><span>Swift?</span><br></blockquote><blockquote type="cite"><span> * Does this proposal fit well with the feel and direction of Swift?</span><br></blockquote><blockquote type="cite"><span> * If you have used other languages or libraries with a similar feature, how</span><br></blockquote><blockquote type="cite"><span>do you feel that this proposal compares to those?</span><br></blockquote><blockquote type="cite"><span> * How much effort did you put into your review? A glance, a quick reading,</span><br></blockquote><blockquote type="cite"><span>or an in-depth study?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>More information about the Swift evolution process is available at</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> <a href="https://github.com/apple/swift-evolution/blob/master/process.md">https://github.com/apple/swift-evolution/blob/master/process.md</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Thank you,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>-Chris Lattner</span><br></blockquote><blockquote type="cite"><span>Review Manager</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>