Hijacking

[Don Clugston]

Regan Heath wrote:
> Walter Bright wrote:
>> kris wrote:
>>> There's a related problem where a public method is added to a 
>>> base-class A (as in your example) but where the signature is 
>>> *exactly* that of one existing in derived class B. If A actually 
>>> calls that new method internally, "bad things"tm will almost 
>>> certainly happen, since B never intended to effectively override the 
>>> newly-added method in A.
>>>
>>> This is a very hard problem to isolate yet can be easily remedied by 
>>> the compiler. The request was first made two or three years back, and 
>>> once or twice since then: you make the "override" keyword *required*.
>>>
>>> When "override" is required, the compiler can easily trap this 
>>> related type of hijacking and avoid such nasty surprises.
>>
>> That is a good point. The reason I haven't added it is because I'm not 
>> sure how annoying it will be to have to always add the 'override' 
>> keyword. It might be one of those things like exception specifications 
>> where everyone says it's a good idea but guiltily hate in secret <g>.
>>
>> Mitigating factors are private and final methods cannot be overridden.
> 
> My vote was, and still is, for 'override' to be mandatory.
> 
> Regan
Me too. Note that since you can use 'override { }' or 'override:', it's less 
onerous than putting 'virtual' in front of every function in C++.