<div dir="ltr">On 4 June 2013 14:16, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Mon, 03 Jun 2013 23:39:25 -0400, Manu <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>> wrote:<br>

<br>
</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"><div class="im">
On 4 June 2013 12:50, Steven Schveighoffer <<a href="mailto:schveiguy@yahoo.com" target="_blank">schveiguy@yahoo.com</a>> wrote:<br>
<br>
</div><div 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">
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>
 You won't break every single method, they already went through that<br>
<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">
recently when override was made a requirement.<br>
It will only break the base declarations, which are far less numerous.<br>
<br>
</blockquote>
<br>
Coming off the sidelines:<br>
<br>
1. I think in the general case, virtual by default is fine.  In code that<br>
is not performance-critical, it's not a big deal to have virtual functions,<br>
and it's usually more useful to have them virtual.  I've experienced plenty<br>
of times with C++ where I had to go back and 'virtualize' a function.  Any<br>
time you change that, you must recompile everything, it's not a simple<br>
change.  It's painful either way.  To me, this is simply a matter of<br>
preference.  I understand that it's difficult to go from virtual to final,<br>
but in practice, breakage happens rarely, and will be loud with the new<br>
override requirements.<br>
<br>
</blockquote>
<br></div><div class="im">
I agree that in the general case, it's 'fine', but I still don't see how<br>
it's a significant advantage. I'm not sure what the loss is, but I can see<br>
clear benefits to being explicit from an API point of view about what is<br>
safe to override, and implicitly, how the API is intended to be used.<br>
Can you see my point about general correctness? How can a class be correct<br>
if everything can be overridden, but it wasn't designed for it, and<br>
certainly never been tested?<br>
</div></blockquote>
<br>
Since when is that on the base class author?  Doctor, I overrode this class, and it doesn't work.  Well, then don't override it :)<br></blockquote><div><br></div><div style>Because it wastes your time (and money). And perhaps it only fails/causes problems in edge cases, or obscure side effects, or in internal code that you have no ability to inspect/debug.</div>
<div style>You have no reason to believe you're doing anything wrong; you're using the API in a perfectly valid way... it just happens that it is wrong (the author never considered it), and it doesn't work.</div>
<div><br></div><div><br></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">
Also there is the possibility that a class that isn't designed from the start to be overridden.  But overriding one or two methods works, and has no adverse effects.  Then it is a happy accident.  And it even enables designs that take advantage of this default, like mock objects.  I would point out that in Objective-C, ALL methods are virtual, even class methods and properties.  It seems to work fine there.<br>
</blockquote><div><br></div><div style>Even apple profess that Obj-C is primarily useful for UI code, and they use C for tonnes of other stuff.</div><div style>UI code is extremely low frequency by definition. I can't click my mouse very fast ;)</div>
<div><br></div><div><br></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">
What I'm really trying to say is, when final is the default, and you really should have made some method virtual (but didn't), then you have to pay for it later when you update the base class.</blockquote><div><br>
</div><div><div>I recognise this, but I don't think that's necessarily a bad thing. It forces you a moment of consideration wrt making the change, and if it will affect anything else. If it feels like a significant change, you'll treat it as such (which it is).</div>
</div><div style>Even though you do need to make the change, it's not a breaking change, and you don't risk any side effects.</div><div><br></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">
When virtual is the default, and you really wanted it to be final (but didn't do that), then you have to pay for it later when you update the base class.  There is no way that is advantageous to *everyone*.<br></blockquote>
<div><br></div><div style>But unlike the first situation, this is a breaking change. If you are not the only user of your library, then this can't be done safely.</div><div><br></div><div><br></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">

<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"><div 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">

2. I think your background may bias your opinions :)  We aren't all<br>
working on making lightning fast bare-metal game code.<br>
<br>
</blockquote>
<br></div><div class="im">
Of course it does. But what I'm trying to do is show the relative merits of<br>
one default vs the other. I may be biased, but I feel I've presented a fair<br>
few advantages to final-by-default, and I still don't know what the<br>
advantages to virtual-by-default are, other than people who don't care<br>
about the matter feel it's an inconvenience to type 'virtual:'. But that<br>
inconvenience is going to be forced upon one party either way, so the<br>
choice needs to be based on relative merits.<br>
</div></blockquote>
<br>
It's advantageous to a particular style of coding.  If you know everything is virtual by default, then you write code expecting that.  Like mock objects.  Or extending a class simply to change one method, even when you weren't expecting that to be part of the design originally.<br>
</blockquote><div><br></div><div style>If you write code like that, then write 'virtual:', it doesn't hurt anyone else. The converse is not true.</div><div><br></div><div><br></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">

I look at making methods final specifically for optimization.  It doesn't occur to me that the fact that it's overridable is a "leak" in the API, it's at your own peril if you want to extend a class that I didn't intend to be extendable.  Like changing/upgrading engine parts in a car.<br>
</blockquote><div><br></div><div style>Precisely, this highlights one of the key issues. Optimising has now become a dangerous breaking process.</div><div><br></div><div><br></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">

<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"><div 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">

3. It sucks to have to finalize all but N methods.  In other words, we<br>
need a virtual *keyword* to go back to virtual-land.  Then, one can put<br>
final: at the top of the class declaration, and virtualize a few methods.<br>
 This shouldn't be allowed for final classes though.<br>
<br>
</blockquote>
<br></div><div class="im">
The thing that irks me about that is that most classes aren't base classes,<br>
and most methods are trivial accessors and properties... why cater to the<br>
minority case?<br>
</div></blockquote>
<br>
I think it is unfair to say most classes are not base classes.  This would mean most classes are marked as final.  I don't think they are.  One of the main reasons to use classes in the first place is for extendability.<br>
</blockquote><div><br></div><div style>People rarely use the final keyword on classes, even though they could 90% of the time.</div><div style>Class hierarchies only typically extend to a certain useful extent, but people usually leave the option to go further anyway. And the deeper the average hierarchy, the more leaf's there are - and the less drastic this change seems in contrast.</div>
<div><br></div><div><br></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">
Essentially, making virtual the default enables the *extender* to determine whether it's a good base class, when the original author doesn't care.<br>
<br>
I think classes fall into 3 categories:<br>
<br>
1. Declared a base class (abstract)<br>
2. Declared NOT a base class (final)<br>
3. Don't care.<br>
<br>
I'd say most classes fall in category 3.  For that, I think having virtual by default isn't a hindrance, it's simply giving the most flexibility to the user.</blockquote><div><br></div><div style>Precisely, we're back again at the only real argument for virtual-by-default: it'll slightly annoy some people to type 'virtual', but that goes both ways. I don't think this supports one position or the other.</div>
<div><br></div><div><br></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"><div 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">
It also doesn't really address the problem where programmers just won't do<br>
that. Libraries suffer, I'm still inventing wheels 10 years from now, and<br>
I'm wasting time tracking down slip ups.<br>
What are the relative losses to the if it were geared the other way?<br>
</blockquote>
<br></div>
The losses are that if category 3 were simply always final, some other anti-Manu who wanted to extend everything has to contact all the original authors to get them to change their classes to virtual :)<br></blockquote><div>
<br></div><div style>Fine, they'll probably be receptive since it's not a breaking change.</div><div style>Can you guess how much traction I have when I ask an author of a popular library to remove some 'virtual' keywords in C++ code?<br>
</div><div style>"Oh we can't really do that, it could break any other users!", so then we rewrite the library.</div><div style><br></div><div style>Who has been more inconvenienced in this scenario?</div><div style>
<br></div><div style>Additionally, if it's the sort of library that's so polymorphic as you suggest, then what are the chances it also uses a lot of templates, and therefore you have the source code...</div><div style>
I think the type of library you describe has a MUCH higher probability of being open-source, or that you have the source available.</div><div><br></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">

BTW, did you know you can extend a base class and simply make the extension final, and now all the methods on that derived class become non-virtual calls?  Much easier to do than making the original base virtual (Note I haven't tested this to verify, but if not, it should be changed in the compiler).<br>
</blockquote><div><br></div><div style>One presumes that the library that defines the base class deals with its own base pointers internally, and as such, the functions that I may have finalised in my code will still be virtual in the place that it counts.</div>
<div><br></div><div><br></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">
<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"><div class="im">
My one real experience on this was with dcollections.  I had not declared<br>
<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">
anything final, and I realized I was paying a performance penalty for it.<br>
 I then made all the classes final, and nobody complained.<br>
<br>
</blockquote>
<br></div><div class="im">
The userbase of a library will grow with time. Andrei wants a million D<br>
users, that's a lot more opportunities to break peoples code and gather<br>
complaints.<br>
Surely it's best to consider these sorts of changes sooner than later?<br>
</div></blockquote>
<br>
I think it vastly depends on the intent of the code.  If your classes simply don't lend themselves to extending, then making them final is a non-issue.<div class="im"><br>
<br>
<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">
And where is the most likely source of those 1 million new users to migrate<br>
from? Java?<br>
</blockquote>
<br></div>
>From all over the place, I would say.  D seems to be an island of misfit programmers.<br>
<br>
-Steve<br>
</blockquote></div><br></div></div>