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

Tue Jul 12 15:54:20 CDT 2016

> Le 12 juil. 2016 à 21:29, Jean-Denis Muys via swift-evolution <swift-evolution at swift.org> a écrit :
> 
>         * What is your evaluation of the proposal?
> 
> I am strongly opposed to that proposal. I am mostly a lurker on this list, the volume of which I cannot cope with. However, I feel this proposal is important enough that I decided to invest more time than usual.
> So I have read carefully the arguments presented here.
> And I am still opposed to the proposal.
> I believe no programmer, least of which myself, can be trusted with the decision to reliably decide ahead of time that this or that class cannot or will not be subclassed.

If you can’t trust a developer, how could you use its library ? Using third-party code involve some kind of trusting, as you would have to trust the developer to write reliable and efficient code, which is IMHO, far more important than knowing if the developer carefully choose what can be subclasses or not.

And when you encounter a library where the dev choose to allow subclassing, you will have far more trust than the code was design to be subclassed.

Some design patterns work better with subclassing than with protocol or delegation. So I’m confident than library developers will ‘open’ there classes if needed.

> So strong -1 for me.
>  
>         * Is the problem being addressed significant enough to warrant a change to Swift?
> 
> I don't think the problem is a problem at all.
>  
>         * Does this proposal fit well with the feel and direction of Swift?
> 
> Not in my mind. Swift aims for safety, but not at the price of inflexibility
> 
> 
>         * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 
> I would compare it for example to the decision for the C++ developer to mark methods virtual or not, with the usual recommendation to mark everything virtual, especially the destructor
> 
>         * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> I read it and ready carefully the debate on this list.
>  
> 
> On Tue, Jul 12, 2016 at 5:36 PM, Jon Akhtar via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I completely agree, the programmer should have as much power as we can
> give them, even if it means allowing them to shoot themselves in the foot,
> because at the end of the day Swift isn¹t an academic exercise, it is a
> real world programming language, so it should be optimized for solving
> real world problems not having some kind of technical, philosophical, and
> stylistic perfection when those come at the cost of the former.
> 
> So -1
> 
> -Jon
> 
> On 7/11/16, 16:00, "swift-evolution-bounces at swift.org <mailto:swift-evolution-bounces at swift.org> on behalf of
> Jonathan Hull via swift-evolution" <swift-evolution-bounces at swift.org <mailto:swift-evolution-bounces at swift.org> on
> behalf of swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> >
> >> On Jul 10, 2016, at 7:48 PM, Rod Brown <rodney.brown6 at icloud.com <mailto:rodney.brown6 at icloud.com>> wrote:
> >>
> >>> On 11 Jul 2016, at 12:33 PM, Jonathan Hull <jhull at gbis.com <mailto:jhull at gbis.com>> wrote:
> >>>
> >>> It is pre-breaking in that it is the exact same code that doesn¹t work
> >>>in both cases (only in the pre-breaking case, a bunch of other code
> >>>also doesn¹t work).  I know it feels different because it ³was never
> >>>possible² vs our change being the cause, but it is one of those things
> >>>like me giving you $5 or giving you $10 and later taking back $5.  As
> >>>humans we are loss averse so we devise strategies to hide the loss from
> >>>ourselves.
> >>
> >> I completely disagree with this.
> >>
> >> Not providing someone something due to risk of breakage is not the same
> >>thing as ³giving it and taking it away². We don¹t build bridges out of
> >>spare parts and tell people ³We build it but we expect it to break at
> >>some stage, so use with caution.² You either build it correctly, or you
> >>don¹t let people cross the bridge. At All.
> >>
> >> This isn¹t about ³loss averse². This is about risk management.
> >>
> >> Where does the line lie on risk? That¹s ultimately something the core
> >>team will have to decide.
> >
> >My point is that you are completely ignoring an entire class of risk that
> >has a real-world $$$ cost.  Every time I have to use a framework under
> >this proposal, I am now completely at the mercy of the author.  In the
> >case of open source frameworks I can at least make a fork, but for closed
> >source frameworks (often from large companies where us using their
> >framework has been negotiated by the bosses) you have now just added
> >weeks to my development cycle while I wait for
> >big-company-who-doesn¹t-really-care-that-much to update their stuff.
> >(sure I can work on other things during that time, but delaying a launch
> >isn¹t free)
> >
> >Are you offering to explain to my boss/client why I can¹t add the feature
> >in a reasonable timeframe like I can with Objective C frameworks?  That
> >it may not even be possible now in Swift even though the Android guy just
> >did it in a few hours?
> >
> >Do you know what I am going to tell my boss/client?  "Don¹t use Swift for
> >frameworks² and ³Try to avoid partnering with companies that have Swift
> >frameworks².  "It is too much of a risk".  "We are giving them too much
> >control over the future of our productŠ"  I mean, it even affects the
> >prices that companies can charge for crappy frameworks. If I am asking
> >for a bunch of features that I NEED them to add to provide a basic
> >feature, that affects negotiations/price (vs a world where I can add it
> >myself if needed).  Sealed-by-default gives them leverage.
> >
> >To use your bridge analogy, which is better in the case that you haven¹t
> >provided a bridge for me:
> >1) I build my own bridge knowing that I will need to maintain it
> >periodically (usually on a predictable schedule)
> >2) Have everyone wait for 6 months (loosing $ the whole time) while I
> >plead with you to build the bridge for me.
> >
> >By definition, the least thought through frameworks are the ones most
> >likely to need workarounds, but under this proposal, they are also the
> >ones we will be unable to fix.  I think some people think that this
> >proposal will make them fix those frameworks or make them disappearŠ but
> >they are often from big brand name companies, who don¹t care that much
> >because tech isn¹t their main business.  In my experience, we can get the
> >changes we need, but it takes anywhere from 2 months to a year.  Being
> >able to patch in a stop-gap while we are waiting is very important for
> >the health of the business.
> >
> >For example, I had a recent client that called me in a panic
> >(unfortunately I have somehow gotten a reputation as someone to call for
> >impossible tasks) because they had a demo they needed to show for a
> >potential multimillion dollar deal and it just wasn¹t working.  The tech
> >they had used as a base wasn¹t doing what it was supposed toŠ and the
> >fixes were 3-6 months away (the demo was a week and a half away).  I
> >would call the support guy for the tech, and they would tell me ³that
> >isn¹t possible yet. Just wait for the update².  I would call them back a
> >couple of hours later saying ³If someone else asks, here is how I did
> >itŠ²  Was that code beautiful? No.  Did I get all the features in that
> >demo working?  Yes, with something like 1 hour to spare.  The demo went
> >very very well.
> >
> >Should I have let that deal fall through because it wasn¹t the ³proper²
> >ideological way to write code?  Sometimes things just need to get done
> >and there isn¹t another wayŠ.  A few people have suggested that these
> >types of concerns aren¹t relevant, but I find them very relevant to my
> >everyday life.  This is the first proposal with the ability to actually
> >cost me (and my clients) money.
> >
> >I am completely ok with needing to type ³unsafe² (or similar) to
> >acknowledge and take responsibility for my actions in those situations.
> >I understand those modifications might break when the framework is
> >finally updated in 3-6 months (hopefully we can even remove them at that
> >point).  Just don¹t ³safety" my clients out of business by making working
> >around bad frameworks impossible.
> >
> >One last analogy.  At a restaurant, they might be afraid I would cut
> >myself with a sharp knife.  They don¹t force me to wear mittens or
> >otherwise make using knifes impossible.  They give everyone butterknives,
> >but I can always get a real knife if I ask for one.  If I order steak, I
> >don¹t even have to askŠ they just bring me a real knife.  This is how
> >Swift has been and should continue to be IMHO.  Prevent me from
> >subclassing accidentally, but if I acknowledge the risk, let me do it.
> >³Safe-by-default² != ³Impossible-by-default²
> >
> >Thanks,
> >Jon
> >
> >P.S. This discussion is reminding me of one of my favorite blogs.  He
> >often talks about the tension between doing things right, and actually
> >getting out there and doing things.  Here is a good/relevant article:
> >http://prog21.dadgum.com/87.html <http://prog21.dadgum.com/87.html>
> >
> >
> >-
> >-
> >_______________________________________________
> >swift-evolution mailing list
> >swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> >https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160712/3394a256/attachment.html>