Re: Generic Collection

[andrew <andrew.carroll@okstate.edu>]

On May 10, 2:31 pm, Simon Wright <simon.j.wri...@mac.com> wrote:
> andrew <andrew.carr...@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.- Hide quoted text -
>
> - Show quoted text -

So I think you are saying I would have one Collection package and it
has three procedures called Add and they operate on three different
types:
Tuple
Table
Schema

but then how do I later use the collection package for some other
purpose?  What if I want to add Colors to a collection?  My goal would
be to Add almost "anything" to the collection instance.  Overloading
only gives me the add methods for tuple, table and schema; I'd have to
go implement another overload for colors IF colors, tuple, table,
schema didn't extend some "Object" type for which all could be stored
in the collection as "Object".

I don't understand why I would have run-time errors.  Please expand
that thought.