Re: Generic Collection

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

On May 12, 2:18 am, Simon Wright <simon.j.wri...@mac.com> wrote:
> andrew <andrew.carr...@okstate.edu> writes:
> > 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?
>
> I would probably end up with a package for each, with appropriate Add
> operations.
>
> with Tuples;
> package Tables is
>   type Table is private;
>   procedure Add (To : in out Table; Item : Tuples.Tuple);
>   ...
> private
>   ...
>   package Tuple_Containers
>   is new <generic-container-package> (Items => Tuples.Tuple);
>   type Table is record
>     Items : Tuple_Containers.Container;
>     ...
>   end record;
>   ...
>
> where you get the fun of choosing which generic-container-package to
> use (Ada.Containers would be a good start) or writing your own.
>
> I can't see what possible advantage you'd get from being able to add a
> Colour to a Schema! If you make a container that can contain anything
> you will need to have runtime checks to enforce this sort of rule
> rather than compile-time checks. Elsewhere in this thread you seemed
> to scoff at this as being a concern; I think classwide programming
> ought to be restricted to the places where it brings you an advantage
> rather than being something that makes your life difficult.

I'm not sure you understand what I'm trying to achieve.  In fact,
sometimes even 'I' am not sure what I am trying to achieve.  Basically
(outside the scope of Ada) I just want a reusable "package" or "class"
or "thing" that provides common procedures, functions to operate on a
collection of like-typed things.  Visual Basic .Net has one called
just that; collection.  Why should I expect not to have one when I use
Ada?

I want to use it for a multitude of things not just attributes,
tables, tuples or schemas.  I just used those as an example and that
may be where the confusion comes in.
Due to the fact that I am not an Ada expert things like "If you make a
container that can contain anything you will need to have runtime
checks to enforce this sort of rule
rather than compile-time checks" means little to me in a visual sense;
I have no refrence to know what the heck you are talking about.
Although I think someone posted something recently when we were
discussing Java's past use of Object.  Maybe that is what you are
referring to.

Not only that but I'm not yet an avid user of generics and I'm quite
certain that my level of understanding of generics will be a barrier
for you.  I won't appologize for that; it's just the way it is.

To me, it makes little sense to make Table, Tuple and Schema a
seperate class or package for each one.  They _abstractly_ are a
collection.  A tuple is a collection of attributes, a table is a
collection of tuples and a schema is a collection of tables.  So
really the only one that is different is tuple and it's different only
in the type of the thing in the collection.  Table and Schema are
"collections of collections".

To test if they are equal would have to be an opperation of the
"thing" that is stored in the collection.  An instance of collection
should be able to call "=" if it's defined on the item in the
collection right?  For that matter any "comparative" operator defined
on the thing in the collection should be accessible; at least that's
what I envision at this time.  Obviously the collection would have to
have it's own comparative operators defined because we might want to
compare two collections.

If we cannot forecast the types of the things stored to be able to
have a comparative operator defined for them then maybe the
stipulation could be made that comparing collections doesn't descend
into comparing the thing that the collection stores.  That would have
to be a auxillary algorithm for the user to implement because there is
no way to be able to forecast what "things" are stored in each
collection nor how to compare them if no comparative operators are
defined OR they don't have a common base type.

So why would we need to give the collection the ability to call the
"=" operator of the things it stores if we agree that the collection
isn't going to descend into comparing the thing that the collection
stores?  Well, I can only say that the stipulation applies only to the
situation where we compare collections.  The collection may have need
to call the "=" operator on the thing it stores to do something like
sort them but not need it for collection to collection comparissons.

So I said all that stuff "my way".  It's probably exactly what you are
trying to tell me.  Just be patient; I'll get it.