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=2.1 required=5.0 tests=BAYES_05,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.software-eng:285 comp.lang.ada:1051 Path: utzoo!yunexus!geac!daveb From: daveb@geac.UUCP (David Collier-Brown) Newsgroups: comp.software-eng,comp.lang.ada Subject: Re: Writing upgradable data structures Message-ID: <2431@geac.UUCP> Date: 10 Mar 88 14:03:07 GMT Article-I.D.: geac.2431 Posted: Thu Mar 10 09:03:07 1988 References: <2307@geac.UUCP> <2767@enea.se> <2417@geac.UUCP> Reply-To: daveb@geac.UUCP (David Collier-Brown) Organization: The G. Yac Co. Ltd/Inc/Pty/Whatever. List-Id: In article <2417@geac.UUCP> Barry Margolin writes: > While I was in the Multics group at Honeywell we did some > investigation of implementing a Multics followon in Ada. I thought > the same thing regarding versioned structures, but I was convinced by > some more experienced Ada people that we could do this using variant > records. When you upgrade the structure you add a new variant. This > does require recompiling users of the structure, but it doesn't force > old, stable programs to be recoded unless they want to take advantage > of the new structure's features. The thing that is hard in Ada[tm] was dealing with a structure which was *later* than the one you expected. Normal Ada scope/recompilation rules keep versioned structures in a linked executable from getting out of date with respect to themselves (with due care, of course), but don't deal well with a structure which is sent to it from something external. Since this technique came from the ARPAnaut world, you might guess that the data structures can be packets... My work-around is to make sure I pass pointers to things, and not depend on the `size attribute (which is not exactly what I'd call good practice... I wonder if its even ethical?). --dave c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.