virtual-by-default rant

F i L witte2008 at gmail.com
Sun Mar 18 04:59:20 PDT 2012


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.




More information about the Digitalmars-d mailing list