Re: Derived private interface

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

On 07.07.11 01:56, Adam Beneschan wrote:
> (3) in the complex case where
> visibility rules cause an inherited operation to disappear, then
> you'll have to figure out what's going on.  Case #3 is the difficult
> one.

Yes, and either way, I think I'll have to think about complex issues
in case #3, with or without indicators, insofar as either issue
(backwards or forwards) will point to the same things. Should
an issue arise.  But point taken, every hint from the compiler
is welcome, the better hint wins.

I guess I'm uneasy with indicators (which I use) because they
purport to solve some problem, but this is just accidental,
and ad hoc, and incomplete in several dimensions.  Maybe something
better is still possible.

If indicators are about doing Ada inheritance properly, here is
an alternative. (That's likely a bold attempt, but anyway.)
Like "overriding", it restricts the language's assistence
to just tagged types.  Instead of adding all indicators,
have the programmer explicitly mention each operation.  Let

  T0 = ({...}, {Op1, ..., OpN}),

then deriving T1 from T0 will list all operations {Op1, ..., OpN}.
(Tools will help the lazy writer.)  For N=2:

   type T0 is abstract tagged private;
   procedure Op1 (X : in out T0) is abstract;
   procedure Op2 (X : in out T0) is abstract;

Then,

   type T1 is abstract new T0 with private;
   procedure Op1 (X : in out T1) is <>;  -- abstract
   procedure Op2 (X : in out T1);  -- overriding
   procedure Op3 (X : in out T1); -- DC

   type T2 is new T1 with private;
   procedure Op1 (X : in out T2);  -- overriding
   procedure Op2 (X : in out T2) is <>; -- inheriting
   procedure Op3 (X : in out T2); -- overriding
   procedure Op4 (X : in out T2); -- DC


Remove T0's Op2. Then, T1 and T2 will have a dispatching
operation that no longer overrides their parent's.  Bad?

Add Op17 to T1. T2 will become invalid because it does
not list Op17. (Fix is to list Op17 using "is <>".)

Add Op3 to T0.  T1's Op3 then becomes overriding. Bad?

Misspelling T2's Op2 renders T2 invalid (because all names
of T1 have to be listed and Op2 will not be listed).
A call on an object of type T2 cannot "by accident"
resolve to a call on T1's.


Eiffel has something similar.  A class inheriting from other
classes will list the features (operations) that it is going
to redefine (override).