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,cc4f25d878383cc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-07 14:51:47 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn4feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc54.POSTED!not-for-mail From: "Mark Lundquist" Newsgroups: comp.lang.ada References: <3C0AACCE.329CFB60@worldnet.att.net> <45601fc.0112031740.3e217c8a@posting.google.com> <3C0CF4E3.A53D20A7@sparc01.ftw.rsc.raytheon.com> <3C0EF0A0.9F42EDB4@adaworks.com> Subject: Dimensions (was Re: Another Idea for Ada 20XX) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <7KbQ7.13821$L51.28784@rwcrnsc54> Date: Fri, 07 Dec 2001 22:51:47 GMT NNTP-Posting-Host: 204.127.202.211 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc54 1007765507 204.127.202.211 (Fri, 07 Dec 2001 22:51:47 GMT) NNTP-Posting-Date: Fri, 07 Dec 2001 22:51:47 GMT Organization: AT&T Broadband Xref: archiver1.google.com comp.lang.ada:17614 Date: 2001-12-07T22:51:47+00:00 List-Id: "Richard Riehle" wrote in message news:3C0EF0A0.9F42EDB4@adaworks.com... > > I don't believe it requires a change to the language. Rather, it begs > for a > simple object-oriented programming solution, along with some > old-fashioned > encapsulation. > > package Metric_Number is > type Metric_Type is private; > -- export services for arithmetic on this type > function "+"(L, R : Metric_Type) return Metric_Type; > -- more arithmetic and boolean functions > private > -- full definition for the Metric_Type; > -- helper type to avoid recursion during implementation > end Metric_Number; I have no idea what you're getting at with the "helper type to avoid recursion"... :-) But in any case, the "good old-fashioned encapsulation" isn't enough (see below)... > > In this way, we can control the behavior of each function with some > exactness > instead of depending only on the predefined behavior of ALRM Chapter 4 > for > numeric types. Of course, if we also had pre- and post-conditions as > part of > the language, this contract could be made even more robust. I don't see how pre- and post-conditions are relevant... ??? But anyway... All these schemes that rely on hiding the representation have some serious weaknesses. First of all, the public view is not scalar. So (a) your type is not compatible with generics that take scalar formals -- you are limited to formal private types; and (b) you cannot declare subtypes with range constraints. (In my opinion (b) is by far the worse of these). (c) it's way labor-intensive But the worst is still to come :-). These schemes are quite brittle and unscalable, because: (d) you have to define all your visibly quasi-numeric operations on every combination of types for base and derived units, so you have a multiplicative explosion on your hands (e) the explosion continues if you want more than one unit per dimension. It explodes in both new overloadings of the quasi-numeric operations, and also in the unit conversions. (f) all the unit types that you wish to be interoperable must be declared in the same package, since they are private, and you can't use child packages for this because then the operations are no longer primitive. It requires "prescience/ominiscience" on the part of the designer, so unless you are really God but you just go by "Richard Riehle" on Usenet :-), it could only be considered for self-contained software where you're "rolling your own" and in complete control of all the code. (g) if you wanted to have multiple types with the same unit relationships but different representations, e.g. different delta, decimal or fixed-point types, you are hosed -- the scheme becomes totally unmanageable at that point. Best Regards, Mark