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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2e66fe8b30e3ee2c X-Google-Attributes: gid103376,public From: Simon Wright Subject: Re: Rep clause problems, was Re: S'Write and How To Count Bytes Date: 2000/10/04 Message-ID: #1/1 X-Deja-AN: 677754574 X-NNTP-Posting-Host: pogner.demon.co.uk:158.152.70.98 References: <39D9DD58.86538032@acm.org> <39DA256D.D854277B@acm.org> X-Trace: news.demon.co.uk 970724148 nnrp-03:23205 NO-IDENT pogner.demon.co.uk:158.152.70.98 Organization: At Home Newsgroups: comp.lang.ada X-Complaints-To: abuse@demon.net Date: 2000-10-04T00:00:00+00:00 List-Id: Marin David Condic writes: > So with my technique, you could avoid the whole mess just so long as > you could absolutely control the representation of a tagged > record. Various suggestions have been made to, for example, put a > well-rep'd record inside the tagged record, but this has problems > with not allowing class-wide operations to be built. You've got to > build a new set of operations for each new type in the class. Yeah, > you can do it, but then you're defeating the elegance of the > solution and forcing a lot of work on building the descendent > types. Also, its tough to come up with good ways of doing things > like checksumming the records and other things that rely on looking > at the whole thing as a unit. I thought you had predefined message formats, which have to be understood by code over which you have little control. So this format will specify field locations and (if you're lucky) endianness. What it certainly won't contain is a space for an Ada tag. Seems to me you need packages to handle the wire formats and packages to handle your tagged types; and when it comes to send a message you might use streams in your tagged type package, but the implementation of the 'Output etc will need to use the appropriate wire format package. And the input wire format package will create and return some object(s) in your tagged world. I'm assuming that your tagged types are in your application domain, not the comms domain? if the former, I've found that messages rarely map at all to application classes; if the latter, the message set rarely maps straightforwardly to any sort of inheritance tree.