[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Thu Jul 7 11:23:54 CDT 2016

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