Manu wrote:
D knows nothing about the class hierarchy when generating code,
I don't know how it can make that claim?
How does D not know about class hierarchy when generating code?
That doesn't make sense to me. It *has* to know to even generate
code.
Anything that's not private can be
extended by another module, and only the linker could ever know
out about that.
This shouldn't be an issue:
export void method() // virtual
export final void method() // non-virtual
Aside from that, I want a compile error if someone tries to
randomly override stuff.
This only really applies if the compiler can't optimize virtuals
away. If the compiler was very good, then getting compiler errors
would only make extending object structure a pain, IMO. I can see
how one programmer might accidentally create a function with the
same name as the base classes name, and how that would be
annoying. That's why...
virtuals are a heinous crime, and should only be used
explicitly. It should not be possible for someone to
accidentally create a virtual.
...I don't think having a virtual keyword would be a bad thing.
Still, I think conceptually saying "you _can't_ override this"
makes more sense than saying "you _can_ override this" when the
biggest reason for using Classes is to build extendable object
types.
I think at the end of the day both arguments are highly
arbitrary. virtual and final keywords could probably exist
peacefully, and wouldn't dent the learning curve by much, so I
don't have any strong argument against virtual. It's just not the
one I'd choose.
