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 <[email protected]> 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 > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
