comp.lang.ada
 help / color / mirror / Atom feed
From: Simon Wright <simon.j.wright@mac.com>
Subject: Re: Generic Collection
Date: Thu, 10 May 2007 20:31:18 +0100
Date: 2007-05-10T20:31:18+01:00	[thread overview]
Message-ID: <m2abwc327t.fsf@mac.com> (raw)
In-Reply-To: 1178736886.994385.37140@y80g2000hsf.googlegroups.com

andrew <andrew.carroll@okstate.edu> writes:

> Since table, tuple and schema are collections I would expect them to
> have the same "capability".  So I would expect to be able to add
> items, delete items, inspect individual items, change individual
> items, sort them, compare them to each other, search them, serialize
> individual items and serialize the whole collection.  That's what I
> see for now.
>
> There was a problem with my example.  Here is the correction
>
> attr1 : attribute;
> attr2 : attribute;
> attr3 : attribute;
> attr4 : attribute;
> attr5 : attribute;
> attr6 : attribute;
>
> tuple1 : collection;
> tuple1.add(attr1);
> tuple1.add(attr2);
> tuple1.add(attr3);
>
> tuple2 : collection;
> tuple2.add(attr4);
> tuple2.add(attr5);
> tuple2.add(attr6);
>
> table1 : collection;
> table1.add(tuple1);
> ...add more tuples to table1
>
> table2 : collection;
> table2.add(tuple2);
> ...add more tuples to table2
>
> schema : collection;
> schema.add(table1);
> schema.add(table2);
>
>
> So, I'm thinking that many of the "capabilities" or operations I
> desire of the collection would have to be "dispatching" to the type of
> the collection object.

Do you want to be able to add attributes to schemas? I would have
thought not ..

If you make all the classes extend the same type they you're likely to
end with run-time errors, which isn't really the Ada Way.

I would have thought you'd want to be able to add Attributes to
Tuples, Tuples to Tables, and Tables to Schemas, and that you'd be
better off looking at overloading.

   procedure Add (To: in out Tuple; Item : Attribute);
   procedure Add (To: in out Table; Item : Tuple);
   procedure Add (To: in out Schema; Item : Table);

If it was me I'd want to distinguish between the 'specification'
aspects defined in the schema and the 'dynamic' aspects defined in the
user data. Your setup seems to mix the two; a Specificaton_Table can
only ever have one Specification_Tuple which is going to define the
number and types of the attributes that each Dynamic_Tuple *must* have
in a (the?) corresponding Dynamic_Table.



  reply	other threads:[~2007-05-10 19:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-08 19:29 Generic Collection andrew
2007-05-08 21:00 ` Georg Bauhaus
2007-05-08 21:59   ` andrew
2007-05-09 14:51     ` andrew
2007-05-09 16:12       ` Georg Bauhaus
2007-05-09 18:54         ` andrew
2007-05-10 19:31           ` Simon Wright [this message]
2007-05-10 22:48             ` andrew
2007-05-11  8:10               ` Georg Bauhaus
2007-05-11 20:41                 ` andrew
2007-05-11 21:28                   ` Georg Bauhaus
2007-05-11 21:55                     ` andrew
2007-05-12  7:18               ` Simon Wright
2007-05-12  7:52                 ` Dmitry A. Kazakov
2007-05-13 11:00                   ` Simon Wright
2007-05-13 12:11                     ` Dmitry A. Kazakov
2007-05-16  0:27                     ` Randy Brukardt
2007-05-16  6:05                       ` Simon Wright
2007-05-16  7:17                         ` Untagged types don't work right - was: " Grein, Christoph (Fa. ESG)
2007-05-16 13:27                       ` Benjamin Place
2007-05-14 17:09                 ` andrew
2007-05-14 20:00                   ` Simon Wright
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox