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

Mon Jul 11 18:18:26 CDT 2016

Thank you for putting your real world scenario out there too. I think you
made some pragmatic points about life of application developers depending
on other companies libraries and I am curious to see more debate on that
point of view.

On Tue, Jul 12, 2016 at 12:00 AM, Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Jul 10, 2016, at 7:48 PM, Rod Brown <rodney.brown6 at icloud.com> wrote:
> >
> >> On 11 Jul 2016, at 12:33 PM, Jonathan Hull <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
>
>
> -
> -
> _______________________________________________
> 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/3c7090ae/attachment.html>