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