Re: I'm facing an issue with: call to abstract procedure must be dispatching

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

On Tue, 8 Dec 2015 12:21:31 -0800 (PST), Serge Robyns wrote:

> At times it proves to be helpful to write a sample test to clear away the
> clutter.  Actually the whole issue appeared because I've been introducing
> the members to the T_Abstract_Data_Store as following:
> 
>    type T_Abstract_Data_Store is abstract tagged limited record
>       Clients: access T_Abstract_Client;  -- was missing 'Class
>       Store2 : access T_Abstract_Store2;  -- was missing 'Class
>    ...

If you really need mix-in then better do it like this:

   type T_Abstract_Data_Store
      (  Clients : not null access T_Abstract_Client'Class;
         Store2 : not null access T_Abstract_Store2'Class
      )  is abstract tagged limited record

This would add a bit more safety, much needed when using access types.

> Now to go back to the overall solution.  This is one of the rare cases
> where multiple inheritance would have made things easier, as then the non
> abstract class would "inherit" from the parents the respective
> implementations like in C++ class T_Store : public T_Store1, public
> T_Store2, ....  Then I could just write "A_Store.Insert (Client);" as this
> was my original code as I had "glue" code in the body of T_Store package,
> overriding all the interfaces.

Why MI is needed here? Of which of two stores is Insert?

There is an ugly method of achieving poor-man's full MI. Full means that
you inherit multiple implementations rather than only interfaces. The
latter is allowed in Ada. The method is that you inherit one implementation
normally and add others through a generic. I don't want to describe it,
because it is really ugly as anything that involves generics. I am not sure
you need full MI in first place.

> I know that this statement will spark some discussions between the two
> "camps" as per Jeffrey's comment.

There are people in c.l.a who believe in procedural decomposition and
inference from the type structure. It is incompatible with fundamental
Ada's principles of strong typing and separation of interface and
implementation. But that is my opinion.

> My only long term concern is how many people can program in Ada?

If you do, that is one man more... Any language lives by people who want to
use it.

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