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,FREEMAIL_FROM, 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-06 09:39:18 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!chcgil2-snh1.gtei.net!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!bos-service2.ext.raytheon.com.POSTED!not-for-mail Message-ID: <3C0FAD3D.64ACC870@usa.com> From: Wes Groleau Reply-To: wgroleau@usa.com X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,es-MX,es,pt,fr-CA,fr MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Another Idea for Ada 20XX References: <3C0AACCE.329CFB60@worldnet.att.net> <45601fc.0112031740.3e217c8a@posting.google.com> <3C0CF4E3.A53D20A7@sparc01.ftw.rsc.raytheon.com> <3C0EF0A0.9F42EDB4@adaworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 06 Dec 2001 12:39:09 -0500 NNTP-Posting-Host: 151.168.144.162 X-Complaints-To: news@ext.ray.com X-Trace: bos-service2.ext.raytheon.com 1007660358 151.168.144.162 (Thu, 06 Dec 2001 12:39:18 EST) NNTP-Posting-Date: Thu, 06 Dec 2001 12:39:18 EST Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:17517 Date: 2001-12-06T12:39:09-05:00 List-Id: Richard Riehle wrote: > 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; However, you have a proliferation of combination functions. function "*" (Left : Some_Metric_Type; Right : Another_Metric_Type) return : One_More_Metric_Type; function "/" (Left : Some_Metric_Type; Right : Another_Metric_Type) return : One_More_Metric_Type; With a reasonably complete facility, the number of left/right/return combinations is huge. Especially if you allow mixed unit addition: function "+" (Left : Meters; Right : Kilometers) return : Meters; Also, this method does not allow attributes and it makes literals slightly more clumsy at best, worse if you consider all the possible ways you can misspell a unit name or use an unrecognized abbreviation for it. (Of course the latter might also be a problem in a "language feature.") I once used an enumerated type for supported units, another for all allowed ways of writing them, a lookup table for standard_form (allowed_written_form), and loads of lookup tables for conversion factors, which type comes from what, etc. That allowed having only one actual type, and only one moderately sized function per operator, but the tables took up a lot of space. Extension and inheritance might have helped some but not a lot. In that particular application, the lack of attributes turned out to be only a minor inconvenience, but I would think it would mean a lot in other cases. Defining a new metric type by inheritance would require knowing all units in the inheritance tree that it could interact with, and providing or overriding the operators to work AND disabling all the operators that would make illegal operations. So I think it wouldn't help any over a non-inherited way. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau