Manu wrote:
I mean it can't possibly know the complete 'final' class
hierarchy, ie, the
big picture. Anything anywhere could extend it. The codegen
must assume
such.
I still don't understand why you think this. The compiler must
understand the full hierarchy it's compiling, and like I said
before, there are very distinct rules as to what should get
virtualed across a lib boundary.
Are you saying someone might accidentally override something
that's not
virtual? That's what 'override' is for. If a method is final,
it is a
compile error to override in any way, you either need to make
the base
virtual, or explicitly 'override' on the spot if you want to do
that.
I was saying that I see how:
class Base { // author: Bob
void commonNamedMethod() {}
}
// ~~~~~
class Foo : Base { // author: Steve
// didn't look at base class, before writing:
void commonNamedMethod() {}
// therefor didn't realize he overwrote it
}
is a valid concern of having things default to virtual. I just
don't think it would happen often, but I've been known to be
wrong.
The virtual methods are the exception, not the common case.
I don't thinks it's so black and white, and that's why I like
having the compiler make the optimization. I think marking
(public) methods you know for sure who's functionality you don't
want overwritten is often a smaller case than methods who's
functionality could *potentially* be overwritten. By letting the
compiler optimize un-overwritten methods, you're giving the Class
users more freedom over the grey areas without sacrificing
performances.
However, I also think the level of freedom is largely dependent
on the situation. Given the fact that you write highly optimized
and tightly controlled core game engine code, I can see why your
perspective leans towards control.
Given this specialization unbalance, I think that both virtual
and final should be available.
Explicit virtual even gives a nice informative cue to
the programmer just how they are supposed to work with/extend
something. You can clearly see what can/should to be extended.
This is a good argument. If nothing else, I think there should be
a way for Class authors to specify (in a way code-completion can
understand) a method attribute which marks a it as being designed
to be overwritten.
I sincerely fear finding myself false-virtual hunting on build
night until
2am trying to get the game to hold its frame rate (I already do
this in
C++, but at least you can grep for and validate them!). Or
cutting content
because we didn't take the time required to manually scan for
false
virtuals that could have given us more frame time.
I think tool that maps hierarchy (showing override) would be best.
like: dmd -hierarchy"map.txt"
You're welcome to it, but granted that, I have an additional
fear that
someone with your opinion is capable of writing classes in libs
that I
might really like to use, but can't, because they are a severe
performance
hazard.
I would argue that any such performance critical libraries should
be tightly "finalized" in the first place. I think you're
assuming the compiler can't, in good faith, optimize out virtual
functions. Whereas I'm assuming it can.
