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.6 required=5.0 tests=BAYES_20,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,e501dbd4bdafeed2,start
X-Google-Attributes: gid103376,public
From: G <Dizzy@interact.net.au>
Subject: null record extension mechanism
Date: 1999/11/10
Message-ID: <38295873.990923A1@interact.net.au>#1/1
X-Deja-AN: 546850799
Content-Transfer-Encoding: 7bit
Organization: Humanity
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-11-10T00:00:00+00:00
List-Id: <comp.lang.ada>

Hi all.   So,  in something like the following :
----------------------
  Type Unit Is (Single, Dependent, Group);

  Type Component Is Abstract Tagged Null Record;
  -- Components are constituent elements in the system.

  Type Component_Unit Is New Component With
  Record
    Simple_Component : Unit := Single;
    Complex_Component : Unit := Dependent;
    Compound_Component : Unit := Group;
  End Record;
-------------------------

  The whole point of having an [abstract][tagged][null][record] is
so that it can be extended.  Is that correct ? It can not itself be
instantiated, but derivations of it can.  So, it appears that one of the

major activities programmers (in this language) undergo is
the careful sculpturing/engineering of types. (?)
  I get lost very easily trying to follow the connections.  It is
apparent
that what I believe to be the representation in the types I make is
not necessarily what I am trying to achieve with them.  The above
fragment
probably means something very different to what I think it does.  It is
very
difficult to work out just how to put concepts together - I guess that
at
some undetermined time in the future, the "penny will drop" and
I will no longer be stumbling in the darkness with this.  I am playing
now
with ideas from the various systems of a specific [rah-66] helicopter.
I find that playing with types
allows me insight into the various systems and their interactions.
  What I am trying to figure out is what base types to make, such that
they nicely encapsulate all the possible derivations that need to be
extended from them.  Is there any useful online information about
strategies for doing this design work ?

thanks,
Graeme

  *hailing from "Down Under", great vast Aussie land of beer and
mosquitoes.*