Le 04/04/2012 10:41, Jonathan M Davis a écrit :
Plus, this isn't a real issue, because the final keyword exists.
It's a _huge_ issue, because it means that nearly every single private
function in a class in D will need to be marked with final in order for it to
be non-virtual and inlinable. The default becomes inefficient, and all just for
NVI.
OK, let me restate this. This isn't a language design issue, this is an
implementation issue. Java and C# finalize function for ages. See below.
At the end, for performance concerns, what we want is that the compiler
or the linker were able to finalize methods that have no override, not
some dirty trick that break larger more important conception principles.
Because of how the compilation model works, that's impossible. No class can
know all of its derived classes. Not only are classes compiled completely
independently of their derived classes, but derived classes could be linked in
dynamically at runtime, and those classes could have been written long after
the base class was written and compiled. So, unless the programmer explicitly
marks a function as final, there's no way that the compiler can know that that
function won't be overridden.
Unless something is marked as export, no code can be linked to it at
runtime. So the linker could finalize any function that isn't export - a
vast majority. It doesn't, I admit. But this is definitively a
implementation issue, and fixing it by language design decision is a
mistake.
It is not that simple. First, it introduce an inconsistency between
interfaces and classes for no real reasons. The only difference between
classes and interfaces should be that interface cannot have member data,
and you can inherit from multiple interfaces. Interface have been
created to solve the problems that exists for multiple inheritance, and
that is enough to solve that problem. Everything else is, again, lack of
separation of concerns.
private is _not_ going to become virtual in classes. I believe that Walter has
stated that it will remain non-virtual (though I'd have to dig through the
newsgroup for the exact quote). The only question is how to handle it in
interfaces, and as far as I know, the intention is to make interfaces follow
TDPL with regards to private.
I know, but Andrei seems to disagree. I also have to dig, to find it,
but I guess we can trust each other on that.
In general, I'm not convinced by the authoritative argument. Both Andrei
and Walter are skilled persons, but they can be wrong, especially when
they don't agree.
If I restate the question, what is the benefit of having classes and
interfaces behaving differently on this point ? TDPL make it pretty
clear how it should be handled in interfaces. Classes should work the
same way. Fixing an implementation issue isn't a valid reason.
Second, the same method can be declared in the base class and in an
interface, and in this case, we cause compile error for nothing.
Why would there be a compilation error? The base class cannot call the
interface's private function, so any reference to that function would be the
base class' function.
You have a class C and an interface I, both define the private method foo.
In MyClass : C, I, if I define foo, I get an error because foo isn't
virtual in C, and if I don't, I don't implement I.
