On 4 June 2013 14:23, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
On 6/4/13 12:13 AM, Manu wrote:
The fact that virtual is a one way trip, and it can not safely be
revoked later and therefore a very dangerous choice as the default is a
maintenance problem.

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.

I don't buy the flexibility argument as a plus. I think that's a mistake, but I granted that's a value judgement.

The fact that I'm yet to witness a single programmer ever declare their
final methods at the time of authoring is a problem.

Too narrow a social circle? :o)

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.
At which point, refer to point #1. He was lucky that he was able to do this without any complaints from customers.
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.
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.


The fact that many useful libraries might become inaccessible to what
I'm sure is not an insignificant niche of potential D users is a problem.

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.)

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).
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.
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.

Even with C++ final-by-default, we've had to avoid libraries because C++ developers can be virtual-tastic sticking it on everything.
D will magnify this issue immensely with virtual-by-default. At least in C++, nobody ever writes virtual on trivial accessors.
virtual accessors/properties will likely eliminate many more libraries on the spot for being used in high frequency situations.

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?
Conversely, if virtual needs to be added at a later time, there are no such nasty side effects. It is always safe.

And I argue the subjective opinion, that code can't possibly be correct
if the author never considered how the API may be used outside his
design premise, and can never test it.

I think you are wrong in thinking traditional procedural testing methods should apply to OOP designs. I can see how that fails indeed.

Can you elaborate?
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?

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.
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.