* [Q] Relationships between tagged types @ 1995-03-01 1:31 John Woodruff 1995-03-03 14:44 ` Tucker Taft 0 siblings, 1 reply; 4+ messages in thread From: John Woodruff @ 1995-03-01 1:31 UTC (permalink / raw) 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. -- John Woodruff Lawrence Livermore National Lab 510 422 4661 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Q] Relationships between tagged types 1995-03-01 1:31 [Q] Relationships between tagged types John Woodruff @ 1995-03-03 14:44 ` Tucker Taft 1995-03-08 12:52 ` Real-time implications of Ada 95 OO features Will Stewart 0 siblings, 1 reply; 4+ messages in thread From: Tucker Taft @ 1995-03-03 14:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Real-time implications of Ada 95 OO features 1995-03-03 14:44 ` Tucker Taft @ 1995-03-08 12:52 ` Will Stewart 1995-03-09 3:45 ` Offer Pazy 0 siblings, 1 reply; 4+ messages in thread From: Will Stewart @ 1995-03-08 12:52 UTC (permalink / raw) I'm looking for information about the effects of late binding, polymorphism, etc with regard to time constraints, and determinism. I did not see much in the Rationale, so is there an FTPable (or hard copy) reference/discussion on the subject? Thanks, Will Stewart ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Real-time implications of Ada 95 OO features 1995-03-08 12:52 ` Real-time implications of Ada 95 OO features Will Stewart @ 1995-03-09 3:45 ` Offer Pazy 0 siblings, 0 replies; 4+ messages in thread From: Offer Pazy @ 1995-03-09 3:45 UTC (permalink / raw) To the best of my knowledge, no such study has been carried out, at least not within the design team. I could envision two areas where there might be effects on real-time analysis and scheduling: 1. The additional overhead (in most unoptimized casees) involving dispatching. You will most likely need to go through an address table and then jump to the approriate subroutine. In my view, this should not affect real-time programs since it merely adds a constant overhehead which is easily measured and factored into the formulas. Looking at a large Ada program as a whole, I would not think that this source of overhead is a significant one (relatively). 2. The second aspect, is the ability to prform pre-runtime scheuling analysis and determining possible paths in the program. With late binding, this problem becomes more complex since you can't see in the code exactly "where you are going". The fact that no compile-time information exists to determine the path that wil be taken eventually, will also make it harder for tools to process such a program. (By the way, I don't know of any tools that does this sort of an analysis on a polymorphic code; if someone has information about such tools, please post or e-mail me.) As a result, you will probably have to factor in the worst case scenario, i.e. choose the longest operation in each case. It's not ideal, but I think people use this worst-case method quite often, anyway. On a side note: Some of Ada 95 "real-time" features are based on the OOP features. At the start of the project, there was much debate whether or not to go this route (that is, use OOP for real-time, or enhance the real-time features independently of OOP). I guess, altimately, we've picked some middle ground (there were much more radical ideas orginally). The areas of scheduling and time management, are largely void of OOP, but features such as storage pool and finalization which may be critical for the reliability (and determinism) of some real-time systems, use tagged types and dispatching. I guess the jury is still out as to whether this was a good approach. My own opinion is that "yes", it might delay a bit the introduction of high-quality (in this area) compilers, but for the long run, it will make Ada much more consistent and reliable. But I'm digressing. Offer ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1995-03-09 3:45 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1995-03-01 1:31 [Q] Relationships between tagged types John Woodruff 1995-03-03 14:44 ` Tucker Taft 1995-03-08 12:52 ` Real-time implications of Ada 95 OO features Will Stewart 1995-03-09 3:45 ` Offer Pazy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox