Thank you! A hyperlink is always so much more substantial than a reasoned claim ;) On 6 Jun 2013 06:05, "Kapps" <[email protected]> wrote:
> On Tuesday, 4 June 2013 at 04:07:10 UTC, Andrei Alexandrescu wrote: > >> Choosing virtual (or not) by default may be dubbed a mistake only in a >> context. With the notable exception of C#, modern languages aim for >> flexibility and then do their best to obtain performance. In the context of >> D in particular, there are arguments for the default going either way. If I >> were designing D from scratch it may even make sense to e.g. force a choice >> while offering no default whatsoever. >> > > C# chose final-by-default not simply because of performance issues but > because of issues with incorrect code. While performance is an issue (much > more so in D than in C#), they can work around that using their JIT > compiler, just like HotSpot does for Java. The real issue is that > overriding methods that the author did not think about being overridden is > *wrong*. It leads to incorrect code. Making methods virtual relies on some > implementation details being fixed, such as whether to call fields or > properties. Many people who wrap fields in properties use the fields still > in various places in the class. Now someone overrides the property, and > finds that it either makes no change or in one or it works everywhere > except in one or two fields where the author refers to the field. By > forcing the author to specifically make things virtual you force them to > recognize that they should or shouldn't be using the property vs the field. > There are many other examples for similar issues, but I feel properties are > one of the biggest issues with virtual-by-default, both from a correctness > standpoint and a performance standpoint. Having @property imply final seems > rather hackish though perhaps. > > Anders Hejlsberg talks about why they decided to use final by default in > C# at > http://www.artima.com/intv/**nonvirtualP.html<http://www.artima.com/intv/nonvirtualP.html>. > See the Non-Virtual is the Default section. They do this *because* they saw > the drawbacks of Java's virtual by default and were able to learn from it. > > Switching to final-by-default doesn't have to be an immediate breaking > change. If we had a virtual keyword it could go through a deprecation > process where overriding a method not declared as virtual results in a > warning, exactly like the override enforcement went through. >
