Re: Derived private interface

["Randy Brukardt" <randy@rrsoftware.com>]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4e15b223$0$6541$9b4e6d93@newsspool4.arcor-online.net...
...
> What instances of Very Bad Things can be removed with the
> help of indicators?

The main one is a routine that did not override when it was expected to. 
This sort of bug cost us many hours of debugging time in Claw, because when 
you trace the logic of the program everything seems correct - just the wrong 
body is being called by dispatching routines and typically you can only 
figure that out by adding tracing to all of the bodies. Ugh!

There are some very subtle visibility-based reasons that a routine will not 
be overriding, and no programmer can be expected to understand those. In 
particular, the "sibling inheritance" problem. The "overriding" indicator 
will at least cause the compiler to complain, and then the programmer can 
spend his time restructuring his entire system rather than pointlessly 
debugging. (This particular problem has no workaround; the package structure 
of the program has to be changed. We tried pretty hard to provide a 
workaround in Ada 2012, but we couldn't do so compatibly or even with just a 
compile-time incompatibility, and a runtime incompatibily is unacceptable. 
Blame interfaces for that - another reason that I hate them. :-) See 
AI05-0125-1 and the associated minutes for the details, if you care.)

                       Randy.

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