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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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 19:55:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!netnews.com!xfer02.netnews.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail From: Richard Riehle Newsgroups: comp.lang.ada Subject: Re: Dimensions (was Re: Another Idea for Ada 20XX) Date: Fri, 07 Dec 2001 19:52:53 -0800 Organization: AdaWorks Software Engineering Message-ID: <3C118E95.B5F013C8@adaworks.com> References: <3C0AACCE.329CFB60@worldnet.att.net> <45601fc.0112031740.3e217c8a@posting.google.com> <3C0CF4E3.A53D20A7@sparc01.ftw.rsc.raytheon.com> <3C0EF0A0.9F42EDB4@adaworks.com> <7KbQ7.13821$L51.28784@rwcrnsc54> Reply-To: richard@adaworks.com NNTP-Posting-Host: 9e.fc.cd.61 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 8 Dec 2001 03:57:50 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:17621 Date: 2001-12-08T03:57:50+00:00 List-Id: Mark Lundquist wrote: > "Richard Riehle" wrote in message > news:3C0EF0A0.9F42EDB4@adaworks.com... > > > > > 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"... :-) In implementing the infix operators for an experimental version of this package, I found myself having to solve the problem of having the full definition of the type as a numeric type itself. > But in any case, the "good old-fashioned encapsulation" > isn't enough (see below)... > 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 Granted. One would be required to write one's own versions of the generics and that would be a really bad idea. Once again, I experimented with this and ended up with some truly baroque code; workable but baroque. > (b) you cannot declare subtypes with range constraints. > (In my opinion (b) is by far the worse of these). Actually, I think (a) is worse than (b). One could define the package as generic and include generic formal parameters for the range constraints. > (c) it's way labor-intensive In experimenting with this idea, I found that I could factor out some properties to make it less labor-intensive than it might seem to be at first glance. Nevertheless, you are correct that it is more labor intensive than the more straigthforward approach orginally suggested. > 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 In fact, I designed some generics to test this and found that the real problems are: 1) no notion of zero, 2) difficult to determine the 'Last and 'First, and 3) most other normally available attributes are not available. > (e) , (f), and (g) from your posting. I give you the points on those. My suggestion, however, does work for some situations. In experimenting with this idea, I decided to export the appropriate mathematical functions after instantiating the generic elementary functions within the body for the abstract number. I agree that the final numeric package is very specialized but it seems to have a small range of applicability for some circumstances. Meanwhile, I am experimenting with other options that might permit a solution without new language features. I will report on my findings if they are at all interesting. Richard Riehle