Re: Derived private interface

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 07.07.11 12:37, Stephen Leake wrote:

> If you don't put 'overriding' on all child operations, they silently
> become non-overriding when the parent changes. Very Bad Things Happen.

An indicator "not overriding" will also "help" when one adds a name
to a parent that had already been used in a child type and has
been duly marked "not overriding" there.
It is only an early hint, though. For example, taking care of LSP
substitutability is not an immediate consequence of the presence
of overriding indicators, but the diagnosis is a start, if not
the best IMHO.

An indicator "overriding" will also help with c&p errors.
For example, when forgetting to adapt parameter profiles to the
child type.

So this is about typos.

What instances of Very Bad Things can be removed with the
help of indicators?

Some of the Very Bad Things happen mostly when the types
do not inherit directly from abstract types or interfaces (as
changing ops will then result in compilation errors).  This,
I think, can be termed The First Bad Thing.

Bad things also happen, more generally, whenever some programming
error would be prevented simply by adding indicators of suitable
sorts that would explain the programmer's intention.  But shouldn't
this kind of information be covered by "normal" language instead?

Or, for an alternative, one might imagine adding a "smart indicator
pragma"

  pragma Fuzzy_Homographs (Threshold => 0.9);

This, then, will prevent frequently quoted errors such as

  Initialse(...) vs Initialize(...).

*Without* restricting the compiler's assistance to just tagged
types!

This, from my point of view, might equip the language with
better means of addressing the real issue, which seems to
be one of naming.