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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1dd28d5040ded1f8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-15 12:15:35 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!kibo.news.demon.net!demon!psiuk-p2!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Announce: Grace project site operational Date: Tue, 14 May 2002 11:45:37 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <3CD88FBD.4070706@telepath.com> <3CD91E31.1060004@telepath.com> <3CDBD673.FF452A3D@otelco.net> <4519e058.0205140718.3ddb1b2a@posting.google.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1021391139 4937 136.170.200.133 (14 May 2002 15:45:39 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 14 May 2002 15:45:39 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:24119 Date: 2002-05-14T15:45:39+00:00 List-Id: Think about why it is that Ada provides separate types with strong rules about separate-but-equal treatment of them. Its about keeping things separate that belong separate. So you need to ask the question "Should these things (almost) never be mixed or confused with each other?" In my produce-inventory-program I (almost) never have a good reason to mix up a count of apples with a count of oranges - hence the archetypical example. But if you're doing computations with velocities and accelerations and such, then you thoroughly intend to mix them and you are then saying "I'm dealing with general mathematical relationships between one thing and another" That sort of calls for a common type of sufficient size to support the anticipated calculations. After all, the common object of interest here is the "mathematical relationship", not the not the particular items in some specific engineering units. I agree that a good compromise is to have subtypes that can then be freely mixed with possible constraints as needed. This provides you with some ability to distinguish in your code where you are dealing with one thing versus another (velocities versus accelerations) and have the values sanity checked by your constraints, while leaving you the ability to freely mix the math operations. Of course, this doesn't save you from everything - e.g. passing a velocity to a function that needs an acceleration - but you just can't always have absolute safety. Absolute safety is for people who don't have the balls to live in the real world. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Ted Dennison" wrote in message news:4519e058.0205140718.3ddb1b2a@posting.google.com... > > That's the biggie. If you try to make separate types for velocities > and accelerations, you will suddenly find that you also need separate > types for times and distances, and perhaps even Hz and mass and forces > and rotational orientations and velocitites and accelerations. Then > you'll find how annoying it is to have to do type conversions on every > factor in every formula. A more attractive option may be to write your > own math operators that return the correct type given their two input > types. But that causes an exponential growth in operators that you > have to create every time you add a new unit. > > To do this kind of thing *right*, you'd really need a language that > relies on structural equivalence for types, and automaticly generates > the proper new type given the operator and the types of its operands. > In Ada, you just can't do that. > > Generally, what I see Ada folk do is use *subtypes* for all this > stuff. That way ranges are checked, but formulas don't become a chore > (although you still have to be really careful with intermediate values > blowing out of subtype constraints). > > -- > T.E.D. > Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) > Homepage - http://www.telepath.com/dennison/Ted/TED.html (down)