[Q] Relationships between tagged types

[Q] Relationships between tagged types

[John Woodruff]

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

Re: [Q] Relationships between tagged types

[Tucker Taft]

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.

Real-time implications of Ada 95 OO features

[Will Stewart]

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

Re: Real-time implications of Ada 95 OO features

[Offer Pazy]

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