[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly
panajev at gmail.com
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
> 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
> 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”
> 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:
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution