Final by default?

[Marco Leise]

Am Mon, 17 Mar 2014 04:37:10 +0000
schrieb "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang at gmail.com>:

> Manu wrote:
> > Whole program optimisation can't do anything to improve the 
> > situation; it
> > is possible that DLL's may be loaded at runtime, so there's 
> > nothing the
> > optimiser can do, even at link time.
> 
> Not really true. If you know the instance type then you can 
> inline.
> 
> It is only when you call through the super class of the instance 
> that you have to explicitly call a function through a pointer.

About two years ago we had that discussion and my opinion
remains that there are too many "if"s and "assume"s for the
compiler.
It is not so simple to trace back where an object originated
from when you call a method on it. It could be created though
the factory mechanism in Object using a runtime string or it
could have been passed through a delegate like this:

  window.onClick(myObject);

There are plenty of situations where it is virtually
impossible to know the instance type statically.
Whole program analysis only works on ... well, whole programs.
If you split off a library or two it doesn't work. E.g. you
have your math stuff in a library and in your main program
you write:

  Matrix m1, m2;
  m1.crossProduct(m2);

Inside crossProduct (which is in the math lib), the compiler
could not statically verify if it is the Matrix class or a
sub-class.

> With a compiler switch or pragmas that tell the compiler what can 
> be dynamically subclassed the compiler can assume all leaves in 
> the compile time specialization hierarchies to be final.

Can you explain, how this would work and where it is used?
  -nosubclasses=math.matrix.Matrix
would be the same as using this in the project, no?:
  final class FinalMatrix : Matrix {}

-- 
Marco