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