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=-1.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,8e0e21432ac3eca6,start
X-Google-Attributes: gid103376,public
From: Nick Roberts <nickroberts@callnetuk.com>
Subject: Re: *\\~record depth~//*
Date: 1999/11/08
Message-ID: <3827113A.DCFE454A@callnetuk.com>#1/1
X-Deja-AN: 546018973
Content-Transfer-Encoding: 7bit
References: <3826DFBF.52AC2680@interact.net.au>
X-Original-NNTP-Posting-Host: da129d247.dialup.callnetuk.com
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Trace: 8 Nov 1999 19:09:16 GMT, da129d247.dialup.callnetuk.com
Organization: Computer Consultant
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-11-08T00:00:00+00:00
List-Id: <comp.lang.ada>

G wrote:
> ...
> I would have thought (my grasp of symbolic logic being as admittedly
> limited as it is) that placing a Simple_Problem within the Complex_
> Problem type would fluff with the compiler. Would there be any 
> programming situations where this sort of thing would apply or is it 
> toally irrelevant ?  

Absolutely not. It's very important to many programming situations to be
able to do this sort of thing.

For example, supposing we have a type:

   type Graphical_Object is abstract tagged null record;

which comes with an operation to draw it on (say) a computer screen:

   procedure Draw (Object: in Graphical_Object) is abstract;

we may derive some obvious types from this:

   type Circle is new Graphical_Object with
      record
         Centre: Raster_Point;
         Radius: Distance;
      end record;

   type Point_Array is array (Positive range <>) of Raster_Point;

   type Polygon (Order: Natural) is new Graphical_Object with
      record
         Corners: Point_Array(1..Order);
      end record;

and so on. However, we might then want ot derive a type which is simply
a collection of other objects:

   type Graphical_Object_Access is access all Graphical_Object'Class;

   type Graphical_Object_Array is 
                array (Positive range <>) of Graphical_Object_Access;

   type Compound_Object (Order: Natural) is new Graphical_Object with
      record
         Cmpts: Graphical_Object_Array(1..Order);
      end record;

Here we have the classic scenario of a widget containing a
wotchamacallit, a wotchamacallit containing an oojamagazzit, and an
oojamagazzit containing more widgets. This sort of thing crops up in
programming all the time.

> If records are included within abstractions of themselves would that
> make it unneccessarily complex to assign properties to instances of
> the records/objects ?

Not at all. Consider my example above. If we had an object Warning_Sign
of type Compound_Object, we could (declare and) initialise it as
follows:

   Warning_Sign: constant Compound_Object :=
   (2, (new Circle'((250,150),50.0), 
        new Polygon'(4, ((100,200),(100,100),(200,100),(200,200)))));

No problem! Furthermore, we can define how to draw compound objects
easily:

   procedure Draw (Object: in Compound_Object) is
   begin
      for i in 1..Object.Order loop
         Draw(Object.Cmpts(i));
      end loop;
   end;

Note how it's possible to have compound objects containing other
compound objects, nested to any depth, and also how this simple
algorithm will nevertheless draw any such compound object correctly (by
automatically recursing as necessary).

-- 
Nick Roberts
Computer Consultant (UK)
http://www.callnetuk.com/home/nickroberts
http://www.adapower.com/lab/adaos