Re: Generic Collection

[Simon Wright <simon.j.wright@mac.com>]

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

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

Ada.Containers. But ...

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

It will certainly be a barrier for _you_, because Ada.Containers is
built round generics.

You could invent your own class Andrews_Object and have
Andrews_Integer inherit from it, then you could have (indefinite)
Ada.Containers containing Andrews_Object'Class. Sounds like a lot of
work.

This is quite close to Java (I'm not sure whether you can use int in
Java or do you have to use a wrapper class? Integer?). I don't think
Ada is that different from C++ here.

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

I think that Table, Tuple and Schema are *concretely* collections. One
clearly different *abstract* thing (ie, something that would be true
in the specification) is eg that it makes no sense to add a Tuple to a
Schema so you ought to try to make it impossible to write (well, to
compile!) code that does that.

In Ada this sort of distinction is normally expressed by 'type Table
is private;' in the public part of the package spec, and having the
full definition, in terms of containers or whatever, in the private
part.

> 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 the container supports this type of operation, you'll see something
like

generic
   type Item is private;
   with function "=" (L, R : Item) return Boolean is <>;
package Some_Container is

At the point where the container generic is instantiated, this syntax
will automatically pick up a visible equality operator for the actual
type corresponding to Item. Or you can specify your own. Same for "<"
etc.

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

If the collection is to support comparison it *must* import an
equality operator. If it is to support sorting it *must* import a
comparison operator. (Sorry, that is certainly true for generics, I
dare say some incredibly complex and possibly unsafe non-generic
scheme could be dreamed up but generics are the way that you do this
sort of thing in Ada!)

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

See above.

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

Hard to find the right angle to approach some of this stuff sometimes!
What seems clear as day to me won't to others ...