If you had money to place for a bounty, what would you choose?

[Manu]

On 3 December 2013 08:43, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org
> wrote:

> On 12/2/13 4:19 AM, Manu wrote:
>
>> The problem is that virtual is irrevocable. It can't be removed without
>> breaking the API
>>
>
> Here we go again. No, that's not the problem. A similar issue goes about
> final.


You can safely add virtual to a function where it wasn't previously present
without breaking code.


 , which means it's not possible to optimise a library in
>> that way at any time after it has already been released to the wild. The
>> converse is not true.
>>
>
> Conversely final makes it impossible tweak behavior after the library has
> been released in the wild. You could reasonably argue that you care more
> about performance optimization than tweaking behavior.


If you're making the kind of library where you want everything to be
overridable, writing 'virtual:' at the top is easy. Do that, you're happy,
and your intentions are made explicit, and there's also no room for error.
It's nowhere near as simple approaching from the other angle, extremely
prone to human error, and if a mistake is made, it it's a breaking
change any time you want to fix it.


 It has also been agreed that there is very little the compiler/optimiser
>> can do to help.
>>
>
> Same goes about "virtualizing" final.


What?


 It's a dangerous default,
>>
>
> How is it "dangerous"?


Because it's a breaking change. You can't add final after it's ever seen
the light of day. No code is fully optimal after revision 0.01b, people
always make mistakes, or react to feedback.
Library authors are always very apprehensive to make breaking changes to
their libs, so it's very hard to get things fixed.
It also requires bumping the major version with semantic versioning to make
performance tweaks, and library authors don't like to do that if they can
avoid it. It creates a situation where it's very hard to get fixes.


 it's got absolutely nothing to do with "I
>> don't want to type final" as you helpfully simplified it. You can type
>> 'virtual:' at the top, and you're set.
>>
>
> Can't _you_ type 'final:' at the top and be set? Why is it that, to
> paraphrase a recent crazy twitter flamewar (http://goo.gl/h9NMxK), your
> Thanksgiving is more important than everybody else's?


No. Classes have virtual functions, that's the point. So you have to micro
manage it.
There is not much sense in a class with 'final:', there is sense in a class
with 'virtual:', if you want to write your code that way, and the intention
is made explicit, which is rarely a bad thing.

With virtual-by-default, there is strong tendency to leave it in it's
default state (everything virtual) because it 'just works', and there's no
warnings or compile errors to remind you what you've committed to.
What I mean is, the author of the code never deliberately made a _choice_,
but they have (probably unknowingly) made a strong commitment. If you're a
library author, you can't correct it later without bumping the major
version, and risk breaking client code.

I don't have thanksgiving; you're welcome to it.
I don't see the parallel, I don't consider this a flamewar.


 Again, the converse doesn't
>> stand, you can't practically type 'final:' at the top since there will
>> inevitable by SOME virtual methods.
>>
>
> Group them before the final: or go through the trouble of typing final {
> ... }.


Just type 'virtual:' at the top. Much simpler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131203/03be6a3f/attachment-0001.html>