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

["Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>]

On 12/08/2015 10:48 AM, Serge Robyns wrote:
> 
> This seems indeed a workable solution.  Actually, in my initial version I had
> one big package for the implementation.  I found this "ugly" and wanted to
> decimate them as per package under the form of child packages.  This also
> allows me to use private types, as children can access private elements.

The point of this approach is that changing the storage method only requires
changing one thing in the entire system. If you need to store private
information then the storage operation needs to be part of the implementation of
the thing with private information, and you lose this advantage. You have to
consider the trade off between the values of keeping the information private and
keeping the storage method in one place.

> My question is then, how can I easily manage this from a source management
> perspective.  As I said in a prior post, changing the "with/use" everywhere
> or use some file system "tricks" to fool the compiler to pick the "right"
> version. Maybe there is some Ada "feature" to do this nicely.  As I said in a
> prior post, in C and C++ I would use the pre-processor to pick the "right"
> one.

I would think that one would use a storage method for a while, and if it proved
unsuitable, switch to another. In such a case, one would simply modify the body
of the pkg, and there would be no source-management issues. You would use your
version-management system (VCS) to revert to the earlier version of that single
file if you decide the change was a mistake.

What you're describing sounds more like maintaining multiple versions that
differ only in their storage method. VCSs don't help with this; generally the
only way to use a VCS to address this is to have multiple branches that differ
only in the 1 file. and merge non-storage changes from one branch to the others.
That can get as messy and hard to do right as having all the implementations in
a single file with all the preprocessor directives for selecting the right one.
Usually additional "make" tools are used to help get it right.

One approach in Ada is to have to body files, and copy the desired one to the
correct name prior to building the system. If the body file name is
Storage.Ada2, for example, you might have bodies Storage_M1.Ada2,
Storage_M2.Ada2, ..., one of which you'd copy to Storage.Ada2 prior to building.
You might use scripts or another "make" tool to reduce the chances of getting it
wrong.

Some people like to use a library-level renaming in cases like this:

with Storage_M2;
package Storage renames Storage_M2;

changing the withed pkg prior to building, but that involves keeping multiple
copies of an identical pkg spec, which is itself a maintenance problem.

Your attempted solution using multiple withs, with all but one commented out, is
similar to this, as the multiple pkgs would all have identical specs. In
addition, you would need at least 1 further change in the unit that withs the
storage pkg.

> I've noticed from your papers you generally disapproves "programming by
> extension".

I investigated it extensively over 2 decades ago and concluded that its negative
qualities outweighed any positive ones. I have not seen anything since to change
my mind. Kazakov, on the other hand, likes multiple inheritance, so you have his
balancing view posting here.

In addition to my papers at

http://pragmada.x10hosting.com/papers.html

you might also be interested in Rosen's paper "What Orientation Should Ada
Objects Take", available at

http://www.adalog.fr/en/publications.html

-- 
Jeff Carter
"Your mother was a hamster and your father smelt of elderberries."
Monty Python & the Holy Grail
06