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

Goffredo Marocchi panajev at gmail.com
Thu Jul 7 11:39:36 CDT 2016 

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 at 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 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
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160707/26734734/attachment.html>

More information about the swift-evolution mailing list