<div dir="ltr">On 4 June 2013 01:28, 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/3/13 3:05 AM, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 3 June 2013 02:37, Andrei Alexandrescu <<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a><br></div><div class="im">
<mailto:<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@<u></u>erdani.org</a>>> wrote:<br>
<br>
    On 6/2/13 9:59 AM, Manu wrote:<br>
<br>
        I've never said that virtuals are bad. The key function of a<br>
        class is<br>
        polymorphism.<br>
        But the reality is that in non-tool or container/foundational<br>
        classes<br>
        (which are typically write-once, use-lots; you don't tend to<br>
        write these<br>
        daily), a typical class will have a couple of virtuals, and a whole<br>
        bunch of properties.<br>
<br>
<br>
    I've argued if no dispatch is needed just make those free functions.<br>
<br>
<br></div><div class="im">
You're not going to win many friends, and probably not many potential D<br>
users by insisting people completely change their coding patterns that<br>
they've probably held for decades on a trivial matter like this.<br>
</div></blockquote>
<br>
This is actually part of the point. You keep on discussing as if we design the language now, when in fact there's a lot of code out there that relies on the current behavior. We won't win many friends if we break every single method that has ever been overridden in D, over a trivial matter.</blockquote>
<div><br></div><div style>You won't break every single method, they already went through that recently when override was made a requirement.</div><div style>It will only break the base declarations, which are far less numerous.</div>
<div style><br></div><div style>How can you justify the change to 'override' with a position like that? We have already discussed that we know PRECISELY the magnitude of breakage that will occur.</div><div style>It is: magnitude_of_breakage_from_override / total_number_of_derived_classes. A much smaller number than the breakage which was gladly accepted recently.</div>
<div style><br></div><div style>And the matter is far from trivial. In fact, if you think this is trivial, then how did the override change ever get accepted? That is most certainly trivial by contrast, and far more catastrophic in terms of breakage.</div>
</div></div></div>