Re: overriding in private part

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 04 Oct 2008 15:47:04 -0400, Robert A Duff wrote:

> If you use a compiler that warns on missing "overriding", then you don't
> need to say "not overriding", because that's the default -- any
> subprogram that doesn't say "overriding" is not overriding.
> Saying "not overriding" is just noise.

[...] 

> I agree that if you want an indicator on every subprogram declaration,
> then forbidding "no overriding" on some non-overriding subprograms is a
> language design mistake.  But I don't want that -- I want a safe
> (non-overriding) default.

But non-overriding is unsafe. Taking your example with in and in-out, when
the programmer uses in instead of in-out, that does not change the program
semantics, so long the program remains legal. Otherwise (if the body
actually changes the parameter) it will not compile. This is safe.

Now, if a procedure is not overriding where an overriding was meant, that
is a semantic change of an unpredictable damage, which slips undetected
through [*]. I think that actually the opposite case is safer. Let the
procedure is an occasional overriding. That does not influence any
type-specific code, because no dispatch happens there. It changes only the
semantics of class-wide code written in terms of parent classes.

There seems to be no safe default.

---------
* Unless the operation is abstract

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de