virtual-by-default rant

[Manu]

On 18 March 2012 13:59, F i L <witte2008 at gmail.com> wrote:

> 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.


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.


> 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...


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.


> 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 see it precisely the other way around. You still need strict control over
precisely HOW to extend that thing. The virtual methods are the exception,
not the common case. 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.
Add to that the requirement for an advanced optimiser to clean up the mess
with LTO, and the fact a programmer can never have confidence in the final
state of the function, I want it the other way around.
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 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.
>

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. It will be a shame if there is eventually a wealth of D libraries,
and only some of them are usable in realtime code because the majority of
programmers are blind to this problem. (Again, this is also common in C++.
I've encountered many libraries over the years that we had to reject, or
even more costly, remove later on after integrating and realising they were
unusable)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120318/cb54e586/attachment.html>