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

[Jon Akhtar]

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 on behalf of
Jonathan Hull via swift-evolution" <swift-evolution-bounces at swift.org on
behalf of 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