<div dir="ltr">On 4 June 2013 14:23, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 6/4/13 12:13 AM, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The fact that virtual is a one way trip, and it can not safely be<br>
revoked later and therefore a very dangerous choice as the default is a<br>
maintenance problem.<br>
</blockquote>
<br></div>
Certainly you're omitting a good part of the setup, which I assume has to do with binary compatibility and prebuilt binaries. In other setups, final is the one-way trip by definition - it restricts potential flexibility.</blockquote>
<div><br></div><div style>I don't buy the flexibility argument as a plus. I think that's a mistake, but I granted that's a value judgement.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The fact that I'm yet to witness a single programmer ever declare their<br>
final methods at the time of authoring is a problem.<br>
</blockquote>
<br></div>
Too narrow a social circle? :o)</blockquote><div><br></div><div style>Well let's consider Steven's example from a short while ago. He didn't write final anywhere, and at some later time, retro-actively introduced it because he realised it was a performance burden.</div>
<div style>At which point, refer to point #1. He was lucky that he was able to do this without any complaints from customers.</div><div style>But it's a breaking change to the API no matter which way you slice it, and I suspect this will be the prevalent pattern.</div>
<div style>So it basically commits to a future of endless breaking changes when someone wants to tighten up the performance of their library, and typically only after it has had time in the wild to identify the problem.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The fact that many useful libraries might become inaccessible to what<br>
I'm sure is not an insignificant niche of potential D users is a problem.<br>
</blockquote>
<br></div>
Not getting this. I dare believe that a competent library designer would be able to choose which functions ought to be overridden and which oughtn't. The moment the issue gets raised, the way the default goes is irrelevant. (But maybe I'm just not getting this.)</blockquote>
<div><br></div><div style>Situation: I have a closed source library I want to use. I test and find that it doesn't meet our requirements for some trivial matter like performance (super common, I assure you).</div><div style>
The author is not responsive, possibly because it would be a potentially breaking change to all the other customers of the library, I've now wasted a month of production time in discussions in an already tight schedule, and I begin the process of re-inventing the wheel.</div>
<div style>I've spent 10 years repeating this pattern. It will still be present with final-by-default, but it will be MUCH WORSE with virtual-by-default. I don't want to step backwards on this front.</div><div style>
<br></div><div style>Even with C++ final-by-default, we've had to avoid libraries because C++ developers can be virtual-tastic sticking it on everything.</div><div style>D will magnify this issue immensely with virtual-by-default. At least in C++, nobody ever writes virtual on trivial accessors.</div>
<div style>virtual accessors/properties will likely eliminate many more libraries on the spot for being used in high frequency situations.</div><div style><br></div><div style>Again, refer to Steven's pattern. Methods will almost always be virtual in D (because the author didn't care), until someone flags the issue years later... and then can it realistically be changed? Is it too late?</div>
<div style>Conversely, if virtual needs to be added at a later time, there are no such nasty side effects. It is always safe.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And I argue the subjective opinion, that code can't possibly be correct<br>
if the author never considered how the API may be used outside his<br>
design premise, and can never test it.<br>
</blockquote>
<br></div>
I think you are wrong in thinking traditional procedural testing methods should apply to OOP designs. I can see how that fails indeed.</blockquote><div><br></div><div style>Can you elaborate?</div><div style>And can you convince me that an author of a class that can be transformed/abused in any way that he may have never even considered, can realistically reason about how to design his class well without being explicit about virtuals?</div>
<div style><br></div><div style>I've made the point before that the sorts of super-polymorphic classes that might have mostly-virtuals are foundational classes, written once and used many times.</div><div style>These are not the classes that programmers sitting at their desk are banging out day after day. This are not the common case. Such a carefully designed and engineered base class can afford a moment to type 'virtual:' at the top.</div>
</div></div></div>