Am 01.06.2013 05:08, schrieb Jonathan M Davis:
On Friday, May 31, 2013 23:59:45 Juan Manuel Cabo wrote:
Making everything final by default would IMO kind of break
automated mock classes generation for unit testing,
automatic proxy class generation for DB entities, and
other OOP niceities.
Then just mark them all as virtual if you don't want to have to worry about
it.
And it wasn't just marking methods final which got the
D version of the raytracer in this thread faster than
the C++ version in the end. (it was a combination of
four or five things, which involved a bit of unrolling,
avoiding array literals, and so on).
Far more than just a raytracer cares about whether functions are virtual, and
no, making member functions non-virtual by default will not suddenly speed up
code everywhere, but there _is_ a cost to having member functions virtual by
default, and there's almost no benefit to it IMHO. And it seems to be folks who
use D in real programs in real companies who most want functions to be non-
virtual by default. Both Don and Manu are completely on board with making
member functions non-virtual by default and hate the fact that they're not.
- Jonathan M Davis
In OO languages where methods are virtual by default, writing mock
classes is usually a matter of extending and overriding said classes.
In languages with final by default, one is forced to use Assembly or
bytecode rewriting tools to be able to override those classes behaviour.
In .NET case the Moles/Pex frameworks from Microsoft research were so
loved by developers that Microsoft made it part of .NET 4.5 under the
name Fake framework.
The same for the C++ with frameworks like Isolator++.
Of course with virtual by default it is also possible to make a method
or class as final, thus causing the same issues with mocking as final by
default does.
Just my .02€ input to the discussion.
--
Paulo
