<div dir="ltr">On 4 June 2013 15:22, 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: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 6/4/13 12:53 AM, Manu wrote:<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">
I don't buy the flexibility argument as a plus. I think that's a<br>
mistake, but I granted that's a value judgement.<br>
</blockquote>
<br></div>
Great.</blockquote><div><br></div><div style>That doesn't mean it's wrong, just that there are other opinions.</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">
But it's a breaking change to the API no matter which way you slice it,<br>
and I suspect this will be the prevalent pattern.<br>
So it basically commits to a future of endless breaking changes when<br>
someone wants to tighten up the performance of their library, and<br>
typically only after it has had time in the wild to identify the problem.<br>
</blockquote>
<br></div>
You're framing the matter all wrongly. Changing a method from virtual to final breaks the code of people who chose to override it - i.e. EXACTLY those folks who found it useful to TAP into the FLEXIBILITY of the design.<br>

<br>
Do you understand how you are wrong about this particular little thing?</blockquote><div><br></div><div style>Well first, there's a very high probability the number of people in that group is precisely zero, but since you can't know the size of your audience, library dev's will almost always act conservatively on that matter.<br>
</div><div style>In the alternate universe, those folks that really want to extend the class in unexpected ways may need to contact the author and request the change. Unlike the situation where I need to do that (where it will probably be rejected), the author will either give them advice about a better solution, or will probably be happy to help and make the change, since it's not a breaking change, and there's no risk of collateral damage.</div>
<div style>There's a nice side-effect that comes from the inconvenience too, which is that the author now has more information from his customers about how his library is being used, and can factor that into future thought/design.</div>
<div style><br></div><div style>Surely you can see this point right?</div><div style>Going virtual is a one-way change.<br></div><div style><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">
Situation: I have a closed source library I want to use. I test and find<br>
that it doesn't meet our requirements for some trivial matter like<br>
performance (super common, I assure you).<br>
The author is not responsive, possibly because it would be a potentially<br>
breaking change to all the other customers of the library, I've now<br>
wasted a month of production time in discussions in an already tight<br>
schedule, and I begin the process of re-inventing the wheel.<br>
I've spent 10 years repeating this pattern. It will still be present<br>
with final-by-default, but it will be MUCH WORSE with<br>
virtual-by-default. I don't want to step backwards on this front.<br>
</blockquote>
<br></div>
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 the behavior of a few methods (super common, I assure you).<div class="im"><br>

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.<br>
</div>
I've spent 10 years repeating this pattern. It will still be present with virtual-by-default, but it will be MUCH WORSE with final-by-default. I don't want to step backwards on this front.<br>
<br>
Destroyed?</blockquote><div><br></div><div style>What? I don't really know what you're saying here, other than mocking me and trivialising the issue.</div><div style>This is a very real and long-term problem.</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">
Even with C++ final-by-default, we've had to avoid libraries because C++<br>
developers can be virtual-tastic sticking it on everything.<br>
</blockquote>
<br></div>
Oh, so now the default doesn't matter. The amount of self-destruction is high in this post.</blockquote><div><br></div><div style>No, you're twisting my words and subverting my point. I'm saying that virtual-by-default will _make the problem much worse_. It's already a problem enough.</div>
<div style>Where once there might be one or 2 important methods that can't be used inside a loop, now there's a situation where we can't even do 'thing.length', or 'entity.get', which appear completely benign, but they're virtual accessors.</div>
<div style>This has now extended the problem into the realm of the most trivial of loops, and the most basic of interactions with the class in question.</div><div style><br></div><div style>The point of my comment is to demonstrate that it's a REAL problem that does happen, and under the virtual-by-default standard, it will become much worse.</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">
D will magnify this issue immensely with virtual-by-default.<br>
</blockquote>
<br></div>
It will also magnify the flexibility benefits.</blockquote><div><br></div><div style>And this (dubious) point alone is compelling enough to negate everything I've presented?</div><div style><br></div><div style>Tell me honestly, when was the last time you were working with a C++ class, and you wanted to override a method that the author didn't mark virtual?</div>
<div style>Has that ever happened to you?</div><div style>It's never happened to me in 15 years. So is there a real loss of flexibility, or just a theoretical one?</div><div style><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">
At least in<br>
C++, nobody ever writes virtual on trivial accessors.<br>
virtual accessors/properties will likely eliminate many more libraries<br>
on the spot for being used in high frequency situations.<br>
</blockquote>
<br></div>
I don't think a "high frequency situation" would use classes designed naively. Again, the kind of persona you are discussing are very weird chaps.</blockquote><div><br></div><div style>No it wouldn't, but everyone needs to make use of 3rd party code.</div>
<div style>And even the internal code is prone to forgetfulness and mistakes, as I've said countless times. Which cost time and money to find and fix.</div><div style><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">
Again, refer to Steven's pattern. Methods will almost always be virtual<br>
in D (because the author didn't care), until someone flags the issue<br>
years later... and then can it realistically be changed? Is it too late?<br>
Conversely, if virtual needs to be added at a later time, there are no<br>
such nasty side effects. It is always safe.<br>
</blockquote>
<br></div>
Again:<br>
<br>
- changing a method final -> overridable is nonbreaking. YOU ARE RIGHT HERE.<br>
<br>
- changing a method overridable -> final will break PRECISELY code that was finding that design choice USEFUL. YOU SEEM TO BE MISSING THIS.<br></blockquote><div><br></div><div style>No it won't break, it wouldn't be there in the first place, because the function wasn't virtual.</div>
<div style>I realise I've eliminated a (potentially dangerous) application of a class, but the author is more than welcome to use 'virtual:' if it's important to them.</div><div style><br></div><div style>
I also think that saying people might want to override something is purely theoretical, and I've certainly never encountered a problem of this sort in C++.<br></div><div style>In my opinion, C++ users often tend to over-use virtual if anything, and I expect that practise would continue unchanged.</div>
<div style><br></div><div>And you've missed (or at least not addressed) why I actually think this is positive.<br></div><div style>Again to repeat myself. I think this sort of code is highly more likely to be open source, it's also highly more likely to contain templates (in which case the source is available anyway), and in lieu of those points, it's also of some benefit for the user that wants to bend this object in an unexpected direction to have some contact with the author. The author will surely have some opinion on the new usage pattern, and will now know the library is being used in this previously unexpected way, and can consider that user-base in the future.</div>
<div style><br></div><div style>Again, both are still possible. But which should be the DEFAULT?</div><div style>Which is a more dangerous default?</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">
        And I argue the subjective opinion, that code can't possibly be<br>
        correct<br>
        if the author never considered how the API may be used outside his<br>
        design premise, and can never test it.<br>
<br>
<br>
    I think you are wrong in thinking traditional procedural testing<br>
    methods should apply to OOP designs. I can see how that fails indeed.<br>
<br>
<br></div><div class="im">
Can you elaborate?<br>
And can you convince me that an author of a class that can be<br>
transformed/abused in any way that he may have never even considered,<br>
can realistically reason about how to design his class well without<br>
being explicit about virtuals?<br>
</div></blockquote>
<br>
I can try. You don't understand at least this aspect of OOP (honest affirmation, not intended to offend). If class A chooses to inherit class B, it shouldn't do so to reuse B, but to be reused by code that manipulates Bs. In a nutshell: "inherit not to reuse, but to be reused". I hope this link works: <a href="http://goo.gl/ntRrt" target="_blank">http://goo.gl/ntRrt</a></blockquote>
<div><br></div><div style>I understand the scripture, but I don't buy it outright. In practise, people derive to 'reuse' just as often (or even more often) than they do to be reused.</div><div style>API's are often defined to be used by deriving and implementing some little thing. Java is probably the most guilty of this pattern I've ever seen, you typically need to derive a class to do something trivial like provide a delegate.</div>
<div style>I'm not suggesting it should be that way, just that it's often not that way in practise.</div><div style><br></div><div style>And regardless, I don't see how the default virtual-ness interferes with the reuse of A in any way. Why do these principles require that EVERYTHING be virtual.</div>
<div style><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">
(If all A wants is to reuse B, it just uses composition.)<br>
<br>
You should agree as a simple matter that there's no reasonable way one can design a software library that would be transformed, abused, and misused. Although class designers should definitely design to make good use easy and bad use difficult, they routinely are unable to predict all different ways in which clients would use the class, so designing with flexibility in mind is the safest route (unless concerns for performance overrides that). Your concern with performance overrides that for flexibility, and that's entirely fine. What I disagree with is that you believe what's best for everybody.</blockquote>
<div><br></div><div style>D usually has quite an obsession with correctness, how can it be safe to encourage use of classes in ways that it was never designed or considered for? Outside of the simplest of classes, I can't imagine any designer can consider all possibilities, they will have had a very specific usage pattern in mind. At best, your 'creative' application won't have been tested.<br>
</div><div style>As new usage scenario's develop, it's useful for the author to know about it, and consider it in future.<br></div><div style><br></div><div style>But this isn't a rule, only a default (in this case, paranoid safety first, a typical pattern for D). A class that wants to offer the flexibility you desire can easily use 'virtual:', or if the author is sufficiently confident that any part can be safely extended, they're perfectly welcome to make everything virtual. There's no loss of possibility, just that the default would offer some more confidence that your usage of a given API is correct; you'll get a compile error if you use beyond the author's intent.</div>
<div style><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">
I've made the point before that the sorts of super-polymorphic classes<br>
that might have mostly-virtuals are foundational classes, written once<br>
and used many times.<br>
</blockquote>
<br></div>
I don't know what a super-polymorphic class is, and google fails to list it: <a href="http://goo.gl/i53hS" target="_blank">http://goo.gl/i53hS</a><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">
These are not the classes that programmers sitting at their desk are<br>
banging out day after day. This are not the common case. Such a<br>
carefully designed and engineered base class can afford a moment to type<br>
'virtual:' at the top.<br>
</blockquote>
<br></div>
I won't believe this just because you said it (inventing terminology in the process), it doesn't rhyme with my experience, so do you have any factual evidence to back that up?</blockquote><div><br></div><div style>
It's very frustrating working with proprietary code, I can't paste a class diagram or anything, but I'm sure you've seen a class diagram before.</div><div style>You understand that classes have a many:1 relationship with their base class?</div>
<div style>So logically, for every 1 day spent writing a base, there are 'many' days working on specialisations. So which is the common case?</div></div></div></div>