Re: Self-referential types

["Matthew Heaney" <matthew_heaney@acm.org>]

In article <3803B5E3.F96A6DD4@mitre.org> , "Robert I. Eachus" 
<eachus@mitre.org> wrote:

>> This is the basis for programming with access discriminants, which is
>> how you do MI in Ada95.
>
>    I have to butt in here.  It may be how you do MI in Ada, and it is
> one way, but I find it ugly.  If you treat a private access type as the
> object, then you have to do a bit more work inside the package, but the
> exterior looks much cleaner, and the users don't have to use 'Access at
> all.  (Often you don't need it inside the package either.)

I think we're in agreement.

I use access discriminants (indeed, taggedness) strictly as an
implementation technique.  As much as possible you want to push the type
composition infrastructure into the private part of the spec.

For example, most of my observer types only privately derive from
Observer_Type; the public part is just "limited private."

with Clock_Timers;
package Digital_Clocks is

  type Digital_Clock (Timer : access Clock_Timer'Class) is
    limited private;

private

  type Control_Type (Clock : access Digital_Clock) is
    new Limited_Controlled with null record;

  type Digital_Clock (Timer : access Clock_Timer'Class) is
    new Observer_Type (Timer) with record
      Control : Control_Type (Digital_Clock'Access);  --!!!
    end record;

end Digital_Clocks;

Here, Digital_Clock "multiply inherits" from two different parent types.
All the machinery is hidden in the private region, exactly where it
belongs.


I do one better when I observe two subjects simultaneously:

with Master_Timers;
with Slave_Timers;
package Digital_Clocks is

  type Digital_Clock
    (Master : access Master_Timer;
     Slave  : access Slave_Timer) is limited private;

private

  type Master_Obs_Type (Clock : access Digital_Clock) is
    new Observer_Type with null record;

  type Slave_Obs_Type (Clock : access Digital_Clock) is
    new Observer_Type with null record;

  type Control_Type (Clock : access Digital_Clock) is
    new Limited_Controlled with null record;

  type Digital_Clock (...) is
    limited record
      Master_Obs : Master_Obs_Type (Digital_Clock'Access);
      Slave_Obs  : Slave_Obs_Type (Digital_Clock'Access);
      Control    : Control_Type (Digital_Clock'Access);
    end record;

end Digital_Clocks;


Here, Digital_Clock "multiply inherits" from three different parent
types.  But all the machinery is hidden in the private region, exactly
where it should be.

In recent article I showed how to observe individual attributes of a
subject, as compared to observing the subject itself.

If you declare the observer types as children of the subject, then you
can even hide the fact that the subject derives from Subject_Type.

Some guys use public taggedness everywhere with gay abandon.  This is
wrong.  Don't use taggedness unless you need to, and if you do, then
hide it in the private region if you can.

Under no circumstances should you have deep inheritance hierarchies.
Make hierarchies broad and shallow; say, an abstract parent type and a
non-abstract sibling derivations.  (This is the approach I use over and
over again in my articles in the Design Patterns archive.)

I realize this is not the OO approach of other languages, but the
benefits are that you have far less coupling.

These examples (and many more) can all be found in the design patterns
archive.

<http://www.acm.org/archives/patterns.html>


I will be discussing this technique this Sunday (17 Oct 99) during my
Design Patterns tutorial, at this year's SIGAda conference.

Matt


--
The political forces that try to eliminate evolution from science
classrooms impose a narrow, sectarian doctrine on our educational
systems. This imposition represents an affront not only to the
constitutional separation of church and state but also to the moral and
intellectual integrity embedded in that constitution.

<http://www.nabt.org/evolutionks.html>