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=ham 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-16 02:15:11 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!nycmny1-snf1.gtei.net!news.gtei.net!colt.net!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!fu-berlin.de!uni-berlin.de!pec-19-95.tnt6.hh2.uunet.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Announce: Grace project site operational Date: Thu, 16 May 2002 11:16:41 +0200 Message-ID: References: <4519e058.0205140718.3ddb1b2a@posting.google.com> <3CE15D0A.3050100@mail.com> <2s44eu0fm4g6606h9p4stb1b5oc0nmg5u8@4ax.com> <3CE2A946.5030808@mail.com> NNTP-Posting-Host: pec-19-95.tnt6.hh2.uunet.de (149.225.19.95) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1021540508 22481168 149.225.19.95 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:24164 Date: 2002-05-16T11:16:41+02:00 List-Id: On Wed, 15 May 2002 14:30:30 -0400, Hyman Rosen wrote: >Dmitry A. Kazakov wrote: > > I believe that an improvement of Ada's ADT/OO gears is > > much more important than any investments in inherently > > flawed generics-templates-macros. > >There were no macros in my C++ code, and there are no macros >in Ada. Generics/templates are not inherently flawed. In short, generics are macros. >> Generally, I dislike any type-based solution of the unit problem. >> I believe that the right way is a subtype-based, OO-ish one. > >Yes, that seems to go along with your "inherently flawed". >You're wrong, because units exist, even in the real world, >only to serve as type tags. The operations on them are just >pure arithmetic on the values they represent; the unit itself >plays no part in the calculation. (Aside from the silly biased >temperature units, which are just dispensed with by working in >Kelvin.) I do not see why the above should serve an argument against a subtype-based solution. Generics are bad for units because they enforce dimensioned values be of unrelated types. Note that it has nothing to do with strong typing and compile-time checks. All that can be done with subtypes. >I fail to see the need for any OO approach to units. >What are you placing in derived types which is different from >the base type? Nothing. The derived type is just another subtype to enforce compile-time type checking. For instance, a discriminant-based variant: type Measure (SI : Unit := Unitless) is record Gain : Number; end record;) You can derive a subtype from it by constraining: subtype Speed is Measure (Velocity); subtype Length is Measure (Distance); Now: X : Speed; Y : Length; X := Y; -- Constraint_Error It is absolutely safe, and a decent Ada compiler should give you warning at compile time. >Why do you want run-time dispatching? How do you write a Put for dimensioned values? It shall be class-wide = work on all unit [sub]types. Do you want to make it generic and instantiate each time? Consider a real-world application. There is a roller dynamometer. It has thousands of sensors and actors, many of them are just analogue inputs/outputs. It has a human interface with hundreds virtual instruments capable to indicate readings in any unit. The operator can configure measurement channels dynamically. Nobody knows which unit will have the input channel 1208 next day. Nobody knows whether the gauge X on the panel Y will show the velocity in km/h or in mph. With a type-based units implementation you will be lost. A real unit solution should combine compile-time checks and effective removal of unit information when it is statically known, with an ability to deal with measures of unknown dimension with checks at run-time.