From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.225.138 with SMTP id rk10mr1513730obc.40.1449606091633; Tue, 08 Dec 2015 12:21:31 -0800 (PST) X-Received: by 10.182.247.67 with SMTP id yc3mr29876obc.0.1449606091609; Tue, 08 Dec 2015 12:21:31 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!mv3no13515001igc.0!news-out.google.com!f6ni17203igq.0!nntp.google.com!mv3no10627931igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 8 Dec 2015 12:21:31 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=109.88.54.35; posting-account=6m7axgkAAADBKh082FfZLdYsJ24CXYi5 NNTP-Posting-Host: 109.88.54.35 References: <8bc7fd76-f00a-4eea-9715-470af028fc84@googlegroups.com> <1krm4xun4e4ny.jmh9kvf6s0a9.dlg@40tude.net> <12dc7aea-933d-4271-95bd-10df808917e4@googlegroups.com> <5hfb2q9imjfu.zs3xp9gxw0d3.dlg@40tude.net> <5788b259-8886-4ee2-8c3d-7799abfd840e@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <14acd8b0-a5e9-40fd-b7cc-d319f914d507@googlegroups.com> Subject: Re: I'm facing an issue with: call to abstract procedure must be dispatching From: Serge Robyns Injection-Date: Tue, 08 Dec 2015 20:21:31 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:28717 Date: 2015-12-08T12:21:31-08:00 List-Id: At times it proves to be helpful to write a sample test to clear away the c= lutter. Actually the whole issue appeared because I've been introducing th= e 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 h= aven't yet fully figured out when it is best use limited and when no= t for my cases. So far I can use limited as I don't need the assignment fo= r T_Store. Likewise from you here I try to avoid access variable as much a= s 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 actual= ly "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 wher= e multiple inheritance would have made things easier, as then the non abstr= act class would "inherit" from the parents the respective implementations l= ike in C++ class T_Store : public T_Store1, public T_Store2, .... Then I c= ould 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 interf= aces. I know that this statement will spark some discussions between the two "cam= ps" as per Jeffrey's comment. Yes, the Ada compiler and language is very cruel but I learned to appreciat= e because often, if not always, highlights (potential) bugs lurking around.= In other languages they don't distinguish between class wide and non clas= s wide, whereas Ada is very picky about it. This is what keeps me trying t= o 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 so= me_id;" that equates to "type some_id : Integer;" instead of "typedef some_= id int;" that equates to "subtype some_id : Integer;" and dynamic_cast which performs run-time conversion checks just like Ada does (exce= pt it creates a null pointer and Ada an understandable exception) and by wh= ich 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 so= meone writing he use Ada for his prototyping/design and then implementing i= t the target language. I could follow that line of thought as Ada is reall= y helping me to get things "right" but I don't feel like rewriting 1000's o= f code. That last paragraph sounds almost like a "message in a bottle" .... Serge