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=0.6 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY,YOU_INHERIT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a1ce307c10055549 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-12-21 08:00:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!arclight.uoregon.edu!wn14feed!worldnet.att.net!207.217.77.102!newsfeed2.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: calenday (was Re: IBM Acquires Rational Ada Date: Sat, 21 Dec 2002 10:59:34 -0500 Organization: MindSpring Enterprises Message-ID: References: <5JfM9.395655$P31.145145@rwcrnsc53> <1040410199.497867@master.nyc.kbcfp.com> NNTP-Posting-Host: d1.56.ba.29 X-Server-Date: 21 Dec 2002 16:00:05 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:32161 Date: 2002-12-21T16:00:05+00:00 List-Id: Not at all true. Many message protocols look very much like an Object Oriented thing with a base class and many derived classes. It is extremely natural to represent this as a tagged record. Not so much because you expect to transmit the tag itself, but because you expect to process your messages internally with all sorts of dispatching and inheretance and stuff like that. It is extremely natural to do this in an OO way. What you need to do though is to control the representation of everything that comes after the tag. You look at your communication link and once you determine the appropriate type of message, you're doing an overlay or unchecked conversion or something similar to get the bytes into the tagged record and then go do your dispatching from there. The thing is, without the tagged record, you end up building your own dispatching and inheritance and things like that anyway. (Big case statements, similarly named procedures or procedures common to all message types, etc.) You're either going to do it with a lot of bit-twiddling and extra work or you can do it with tagged records very cleanly. If you've got two Ada programs talking to each other and they're built by the same compiler, representation can become a "don't care" issue - maybe. If its on a more heterogeneous plane, you've got to be sure you control representation. So I don't really think the issue is all that abstract or theoretical - it does occur in the real world often enough and you'd just like to take advantage of tagged records & representation to make it work nicely. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "I'd trade it all for just a little more" -- Charles Montgomery Burns, [4F10] ====================================================================== Frank J. Lhota wrote in message news:zuKM9.66886$4W1.13625@nwrddc02.gnilink.net... > "Hyman Rosen" wrote in message > news:1040410199.497867@master.nyc.kbcfp.com... > > The whole concept of representation specs on tagged > > records seems pretty dodgy to me. > > I agree. AFAIK, the only reason to use a representation clause is to make > sure that a type matches some external data layout. Tagged types, by their > very nature, do not fit into this category. This seems to be one of those > theoretical issues with no practical consequences. > >