Final by default?

[Regan Heath]

On Thu, 13 Mar 2014 21:42:43 -0000, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 3/13/2014 1:09 PM, Andrei Alexandrescu wrote:
>> Also let's not forget that a bunch of people will have not had contact  
>> with the
>> group and will not have read the respective thread. For them -- happy  
>> campers
>> who get work done in D day in and day out, feeling no speed impact  
>> whatsoever
>> from a virtual vs. final decision -- we are simply exercising the brunt  
>> of a
>> deprecation cycle with undeniable costs and questionable (in Walter's  
>> and my
>> opinion) benefits.
>
> Also,
>
>      class C { final: ... }
>
> achieves final-by-default and it breaks nothing.

Yes.. but doesn't help Manu or any other consumer concerned with speed if  
the library producer neglected to do this.  This is the real issue,  
right?  Not whether class *can* be made final (trivial), but whether they  
*actually will* *correctly* be marked final/virtual where they ought to be.

Library producers range in experience and expertise and are "only human"  
so we want the option which makes it more likely they will produce good  
code.  In addition we want the option which means that if they get it  
wrong, less will break if/when they want to correct it.


Final by default requires that you (the library producer) mark as virtual  
the functions you intend to be inherited from.  Lets assume the library  
producer has a test case where s/he does just this, inherits from his/her  
classes and overrides methods as they see consumers doing.  The compiler  
will detect any methods not correctly marked.  So, there is a decent  
chance that producers will get this "right" w/ final by default.

If they do get it wrong, making the change from final -> virtual does not  
break any consumer code.


Compare that to virtual by default where marking everything virtual means  
it will always work, but there is a subtle and unlikely to be  
detected/tested performance penalty.  There is no compiler support for  
detecting this, and no compiler support for correctly identifying the  
methods which should be marked final.  In fact, you would probably mark  
them all final and then mark individual functions virtual in order to  
solve this.

If they get it wrong, making the change from virtual -> final is more  
likely to break consumer code.


I realise you're already aware of the arguments for final by default, and  
convinced it would have been the best option, but it also seems to me that  
the "damage" that virtual by default will cause over the future lifetime  
of D, is greater than a well controlled deprecation path from virtual ->  
final would be.

Even without a specific tool to aid deprecation, the compiler will output  
clear errors for methods which need to be marked virtual, granted this  
requires you compile a program which "uses" the library but most library  
producers should have such a test case already, and their consumers could  
help out a lot by submitting those errors directly.

Regan.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/