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

[Serge Robyns <serge.robyns@gmail.com>]

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

Before it was a limited interface and hence no record.  This reminds me I haven't yet fully figured out when it is <b>best</b> use limited and when not for my cases.  So far I can use limited as I don't need the assignment for T_Store.  Likewise from you here I try to avoid access variable as much as possible but at times I've no choice, well at least I use programming by extension ...

My real Do_Something was already having A_Store : in out T_A..._S...'Class) however I was using
     A_Store.Clients.Insert (Client);
I've been looking and re-looking at "A_Store" whilst the problem was actually "Clients", which was lacking 'Class;  I've been misled as I got so used that the Ada compiler is very good at error handling, so much better than g++ or maybe I didn't read the column number properly (shame on me!).

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.

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

Yes, the Ada compiler and language is very cruel but I learned to appreciate because often, if not always, highlights (potential) bugs lurking around.  In other languages they don't distinguish between class wide and non class wide, whereas Ada is very picky about it.  This is what keeps me trying to pursue with Ada, even if the latest C++ offers a few nice things without getting it right although.  Such as for example; "typedef enum class int some_id;" that equates to "type some_id : Integer;" instead of "typedef some_id int;" that equates to "subtype some_id : Integer;"  and dynamic_cast<class_xyz*> which performs run-time conversion checks just like Ada does (except it creates a null pointer and Ada an understandable exception) and by which I got already caught once.

My only long term concern is how many people can program in Ada?  Who will later be able to maintain my code?  I've high respect to people like Dmitry, David and others who are putting a lot of their time maintaining various projects.  But this could become my "killing" concern.  I recall reading someone writing he use Ada for his prototyping/design and then implementing it the target language.  I could follow that line of thought as Ada is really helping me to get things "right" but I don't feel like rewriting 1000's of code.

That last paragraph sounds almost like a "message in a bottle" ....

Serge