Re: null record extension mechanism

Re: null record extension mechanism

[Matthew Heaney]

In article <38295873.990923A1@interact.net.au> , G 
<Dizzy@interact.net.au>  wrote:

>   The whole point of having an [abstract][tagged][null][record] is
> so that it can be extended.  Is that correct ?

That's the point of tagged types.  A tagged null record just happens not
to have any components; it's like counting by starting at zero.


> It can not itself be
> instantiated, but derivations of it can.

That's what an abstract tagged type is.  You'd typically declare a
tagged type as abstract because you have an abstract operation.


> So, it appears that one of the major activities programmers (in this language)
> undergo is the careful sculpturing/engineering of types. (?)

Yes.  That's the essence of object-oriented programming: programming
with abstractions, implemented as types.


> 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.

That's exactly right.  Just keep doing it, and you'll learn it.


> Is there any useful online information about strategies for doing this design
> work ?

Do an online search for "object-oriented programming," and see what
drops out.  There's a web-site, called Cetis-Links or something like
that, that has all the OO technology stuff you could ever want.

Matt

--
Why stop at evolution and cosmology, though? Let's make sure that the
schoolkids of Kansas get a really first-rate education by loosening up
the teaching standards for other so-called scientific ideas that are,
after all, just theories. The atomic theory, for example. The theory of
relativity. Heck, the Copernican theory--do we really know that the
universe doesn't revolve around the earth?

John Rennie, Scientific American, Oct 1999

null record extension mechanism

[G]

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.*