<div dir="ltr">On 4 June 2013 12:50, Steven Schveighoffer <span dir="ltr"><<a href="mailto:schveiguy@yahoo.com" target="_blank">schveiguy@yahoo.com</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 Mon, 03 Jun 2013 12:25:11 -0400, Manu <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>> wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
You won't break every single method, they already went through that<br>
recently when override was made a requirement.<br></div><div class="im">
It will only break the base declarations, which are far less numerous.<br>
</div></blockquote>
<br>
Coming off the sidelines:<br>
<br>
1. I think in the general case, virtual by default is fine. In code that is not performance-critical, it's not a big deal to have virtual functions, and it's usually more useful to have them virtual. I've experienced plenty of times with C++ where I had to go back and 'virtualize' a function. Any time you change that, you must recompile everything, it's not a simple change. It's painful either way. To me, this is simply a matter of preference. I understand that it's difficult to go from virtual to final, but in practice, breakage happens rarely, and will be loud with the new override requirements.<br>
</blockquote><div><br></div><div style>I agree that in the general case, it's 'fine', but I still don't see how it's a significant advantage. I'm not sure what the loss is, but I can see clear benefits to being explicit from an API point of view about what is safe to override, and implicitly, how the API is intended to be used.</div>
<div style>Can you see my point about general correctness? How can a class be correct if everything can be overridden, but it wasn't designed for it, and certainly never been tested?</div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. I think your background may bias your opinions :) We aren't all working on making lightning fast bare-metal game code.<br></blockquote><div><br></div><div style>Of course it does. But what I'm trying to do is show the relative merits of one default vs the other. I may be biased, but I feel I've presented a fair few advantages to final-by-default, and I still don't know what the advantages to virtual-by-default are, other than people who don't care about the matter feel it's an inconvenience to type 'virtual:'. But that inconvenience is going to be forced upon one party either way, so the choice needs to be based on relative merits.</div>
<div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. It sucks to have to finalize all but N methods. In other words, we need a virtual *keyword* to go back to virtual-land. Then, one can put final: at the top of the class declaration, and virtualize a few methods. This shouldn't be allowed for final classes though.<br>
</blockquote><div><br></div><div style>The thing that irks me about that is that most classes aren't base classes, and most methods are trivial accessors and properties... why cater to the minority case?</div><div style>
It also doesn't really address the problem where programmers just won't do that. Libraries suffer, I'm still inventing wheels 10 years from now, and I'm wasting time tracking down slip ups.</div><div style>
What are the relative losses to the if it were geared the other way?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My one real experience on this was with dcollections. I had not declared anything final, and I realized I was paying a performance penalty for it. I then made all the classes final, and nobody complained.<br></blockquote>
<div><br></div><div style>The userbase of a library will grow with time. Andrei wants a million D users, that's a lot more opportunities to break peoples code and gather complaints.</div><div style>Surely it's best to consider these sorts of changes sooner than later?</div>
<div style><br></div><div style>And where is the most likely source of those 1 million new users to migrate from? Java?</div></div></div></div>