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,c7fe97e7d36f4c57 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-03 08:40:52 PST Newsgroups: comp.lang.ada Path: bga.com!news.sprintlink.net!uunet!noc.near.net!inmet!henning!stt From: stt@henning.camb.inmet.com (Tucker Taft) Subject: Re: [Q] Relationships between tagged types Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. X-Newsreader: TIN [version 1.1 PL8] References: Date: Fri, 3 Mar 1995 14:44:24 GMT Date: 1995-03-03T14:44:24+00:00 List-Id: John Woodruff (woodruff@neux2.llnl.gov) wrote: : I'm trying to teach myself the OO features of Ada95, and sometimes I : get a little stuck. Here is a case where I'd benefit from a little : advice. I suspect that there is an idiomatic structure for modeling : related extensible types, but I'm stumbling. : package Reading is : type Reading_Type is tagged null record ; : -- : -- I hope to model some distinct devices, each kind with its own reading : -- : type continuous_reading is new Reading_Type with record : value : float ; : end record ; : type discrete_reading is new Reading_Type with record : value : integer ; : end record ; : -- I am going to get a reading from one of these devices, : -- using some dispatching operation not shown here, then : -- decide if the reading is significantly out of tolerance: : type Tolerance is record : Upper, Lower : Reading_Type ; -- this is not quite what I want! : end record ; -- but 'class is not correct here : -- I wish I could express the fact that discrete readings are : -- characterized by discrete tolerances, etc ... : -- Now the point of the exercise is to require that continuous : -- readings be tested for significance against continuous tolerances, etc. : -- But I haven't seen how to do this without making the : -- functions try to dispatch on two different parameters : function Significant (Reading : Continuous_Reading ; : Bound : Tolerance) return Boolean ; : function Significant (Reading : Discrete_Reading ; : Bound : Tolerance) return Boolean ; : end Reading ; : The issues I wish I could model in the spec I sketched here are : reading_type can be extended for numerous kinds of devices : each reading_type has a corresponding tolerance type : I want to assure that reading and tolerance values stay paired, so : operations like Significant (and other opn's tbd) will be type-safe : There doesn't seem to be a reason for reference semantics, since I : dont see any cause for sharing access to values (thus I have not used : access types). : I'd be glad to have advice; thanks. The simplest solution is to forego the "Tolerance" data structure and pass the high and low bound as separate parameters to your "Significant" function. Hence, you could declare the following on the root type Reading_Type: function Significant( Reading : Reading_Type; Upper, Lower : Reading_Type ) return Boolean is abstract; The definer of any extension of Reading_Type would have to override this function with a version appropriate to their type. For this to be legal, you would have to declare Reading_Type as abstract as well: type Reading_Type is abstract tagged null record; Perhaps a more fundamental question is whether you really will ever write any code that uses Reading_Type'Class. It might be helpful to sketch out what that code would look like before trying to decide what primitive operations or auxilliary data structures you need to define for Reading_Types. : John Woodruff : Lawrence Livermore National Lab : 510 422 4661 Hope that helps. -Tucker Taft stt@inmet.com Intermetrics, Inc.