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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: "Jeffrey R. Carter" Newsgroups: comp.lang.ada Subject: Re: I'm facing an issue with: call to abstract procedure must be dispatching Date: Tue, 8 Dec 2015 11:46:05 -0700 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: <8bc7fd76-f00a-4eea-9715-470af028fc84@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Injection-Date: Tue, 8 Dec 2015 18:43:40 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="caa759af2a9c666aec02942f6fe5abd6"; logging-data="6913"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18gjZvzxGJtjH+2w73hHRYxeujgAelegko=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: Cancel-Lock: sha1:K2jUcYACfZcYX8hovZhlpd7R6iQ= X-Enigmail-Draft-Status: N1110 Xref: news.eternal-september.org comp.lang.ada:28716 Date: 2015-12-08T11:46:05-07:00 List-Id: 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