Generic Collection

Generic Collection

[andrew]

On Apr 26, 11:07 am, Georg Bauhaus <bauh...@futureapps.de> wrote:
> On Thu, 2007-04-26 at 08:31 -0700, andrew.carr...@okstate.edu wrote:
> > I discovered a possble design mistake in the program I wrote for my
> > Master's course this semester.  It's working and all that but I think
> > I could have saved myself many hours of work had I recognized (and
> > regurgitated from my undergraduate knowledge in 2002) the "is a"
> > concept.  With respect to databases a tuple "is a" collection of
> > attributes and a table "is a" collection of tuples and a schema "is a"
> > collection of tables.  I could have used a generic "collection" to
> > satisfy tuple, table and schema and I wouldn't have had to write code
> > to iterate, add, delete, etcetera from them.
>
> > Does that help explain it?
>
> Are you certain that these high level "is a" relations aren't
> entirely artificial?  What is gained by finding a thin, common
> interface of tuples, tables, and schemata?
>
> In the case you describe, I'd prefer composition over
> inheritance. A table has many tuples, and a table is part
> of a schema. So that alone makes tables collections of tuples,
> for example.
>
> By analogy, every type of a program identifies a collection of
> values. But not every type in a program must be explicitly derived
> from some universal ancestor, even when we could find some remote
> property that it shares with all other types. There is value in
> differentiating objects.
>
> Universal unification of everything leads to answers
> as useful as 42. :)

I cannot say for sure if the "is a" relations aren't entirely
artificial.  It seems to me it would work either way.  The difference
for me is that I cannot visualize the composition you mentioned.




On Apr 26, 2:40 pm, "andrew.carr...@okstate.edu"
<andrew.carr...@okstate.edu> wrote:
>
> Who said anything about derivation?  Yeah, I used the word "is a" but
> that doesn't mean I want to build a whole class tree.  As far as I am
> thinking I just do something like:  package Tuple is new
> Generic_Collection(Item => attribute);
>
> Attribute can implement some kind of file_system interface and can
> iterate by positive count values which are sequential.
>
> Then I could do package Table is new Generic_Collection(Item =>
> tuple.???);
> Then I could do package Schema is new Generic_Collection(Item =>
> table.???);
>
> This is all in a dream world so please don't get to picky with the
> syntax.  So, is there a "Generic_Collection" type of package in Ada?- Hide quoted text -
>


On Apr 26, 3:01 pm, Georg Bauhaus <bauh...@futureapps.de> wrote:
> On Thu, 2007-04-26 at 12:40 -0700, andrew.carr...@okstate.edu wrote:
> > Who said anything about derivation?  Yeah, I used the word "is a" but
> > that doesn't mean I want to build a whole class tree.
>
> Ah, OK.
>
> >   So, is there a "Generic_Collection" type of package in Ada?
>
> AFAIK, not in the sense that permits deciding the nature
> of the collection at runtime, or based on the type parameter
> (see also Dmitry's remarks).
>

So what you are saying is that the type Item in my example is the
parameter you are talking about?

Re: Generic Collection

[Georg Bauhaus]

On Tue, 2007-05-08 at 12:29 -0700, andrew wrote:

> I cannot say for sure if the "is a" relations aren't entirely
> artificial.  It seems to me it would work either way.  The difference
> for me is that I cannot visualize the composition you mentioned.

As you noted, I meant that "a tuple is a collection of attributes"
doesn't necessarily imply inheritance relationship; TUPLE doesn't have
to inherit from a type COLLECTION_OF_ATTRIBUTES.

I think there are various possibilities; RDB2 (below RDB) shows
types that have components of other types (that is, are composed :-)
but are otherwise unrelated.
Package RDB desclares "is a" relations in the sense you describe
by making the DB types be "a collection of" objects of "smaller"
types.


> So what you are saying is that the type Item in my example is the
> parameter you are talking about?

Erh, I guess so.

with Ada.Containers.Hashed_Sets;
with Data;

package RDB is

   use Ada;

   type DP is access Data.T'class;
   function compare(a, b: DP) return BOOLEAN;
   function hash(element: DP) return Containers.HASH_TYPE;


   subtype ATTRIBUTE is DP;

   package Attributes is new Containers.Hashed_Sets
     (ELEMENT_TYPE => ATTRIBUTE,
      hash => hash,
      equivalent_elements => compare);


   subtype TUPLE is Attributes.SET;
   function hash(element: TUPLE) return Containers.HASH_TYPE;


   package Tuples is new Containers.Hashed_Sets
     (ELEMENT_TYPE => TUPLE,
      hash => hash,
      equivalent_elements => Attributes."=",
      "=" => Attributes."=");


   subtype TABLE is Tuples.SET;
   function hash(element: TABLE) return Containers.HASH_TYPE;


   package Tables is new Containers.Hashed_Sets
     (ELEMENT_TYPE => TABLE,
      Hash => hash,
      equivalent_elements => Tuples."=",
      "=" => Tuples."=");

   -- ...

end RDB;


with Ada.Containers.Hashed_Sets;
with Data;

package RDB2 is

   use Ada;

   type DP is access Data.T'class;
   function compare(a, b: DP) return BOOLEAN;
   function hash(element: DP) return Containers.HASH_TYPE;


   subtype ATTRIBUTE is DP;

   package Attributes is new Containers.Hashed_Sets
     (ELEMENT_TYPE => ATTRIBUTE,
      hash => hash,
      equivalent_elements => compare);

   type TUPLE is
      record
         -- ...
         columns: Attributes.SET;
      end record;
   function compare(a, b: TUPLE) return BOOLEAN;
   function hash(element: TUPLE) return Containers.HASH_TYPE;


   package Tuples is new Containers.Hashed_Sets
     (ELEMENT_TYPE => TUPLE,
      hash => hash,
      equivalent_elements => compare);


   type TABLE is
      record
         -- ...
         rows: Tuples.SET;
      end record;
   function compare(a, b: TABLE) return BOOLEAN;
   function hash(element: TABLE) return Containers.HASH_TYPE;


   package Tables is new Containers.Hashed_Sets
     (ELEMENT_TYPE => TABLE,
      Hash => hash,
      equivalent_elements => compare);

   type SCHEMA is
      record
         -- ...
         relations: Tables.SET;
      end record;


end RDB2;

Re: Generic Collection

[andrew]

On May 8, 4:00 pm, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>
wrote:
> On Tue, 2007-05-08 at 12:29 -0700, andrew wrote:
> > I cannot say for sure if the "is a" relations aren't entirely
> > artificial.  It seems to me it would work either way.  The difference
> > for me is that I cannot visualize the composition you mentioned.
>
> As you noted, I meant that "a tuple is a collection of attributes"
> doesn't necessarily imply inheritance relationship; TUPLE doesn't have
> to inherit from a type COLLECTION_OF_ATTRIBUTES.
>
> I think there are various possibilities; RDB2 (below RDB) shows
> types that have components of other types (that is, are composed :-)
> but are otherwise unrelated.
> Package RDB desclares "is a" relations in the sense you describe
> by making the DB types be "a collection of" objects of "smaller"
> types.
>
> > So what you are saying is that the type Item in my example is the
> > parameter you are talking about?
>
> Erh, I guess so.
>
> with Ada.Containers.Hashed_Sets;
> with Data;
>
> package RDB is
>
>    use Ada;
>
>    type DP is access Data.T'class;
>    function compare(a, b: DP) return BOOLEAN;
>    function hash(element: DP) return Containers.HASH_TYPE;
>
>    subtype ATTRIBUTE is DP;
>
>    package Attributes is new Containers.Hashed_Sets
>      (ELEMENT_TYPE => ATTRIBUTE,
>       hash => hash,
>       equivalent_elements => compare);
>
>    subtype TUPLE is Attributes.SET;
>    function hash(element: TUPLE) return Containers.HASH_TYPE;
>
>    package Tuples is new Containers.Hashed_Sets
>      (ELEMENT_TYPE => TUPLE,
>       hash => hash,
>       equivalent_elements => Attributes."=",
>       "=" => Attributes."=");
>
>    subtype TABLE is Tuples.SET;
>    function hash(element: TABLE) return Containers.HASH_TYPE;
>
>    package Tables is new Containers.Hashed_Sets
>      (ELEMENT_TYPE => TABLE,
>       Hash => hash,
>       equivalent_elements => Tuples."=",
>       "=" => Tuples."=");
>
>    -- ...
>
> end RDB;
>
> with Ada.Containers.Hashed_Sets;
> with Data;
>
> package RDB2 is
>
>    use Ada;
>
>    type DP is access Data.T'class;
>    function compare(a, b: DP) return BOOLEAN;
>    function hash(element: DP) return Containers.HASH_TYPE;
>
>    subtype ATTRIBUTE is DP;
>
>    package Attributes is new Containers.Hashed_Sets
>      (ELEMENT_TYPE => ATTRIBUTE,
>       hash => hash,
>       equivalent_elements => compare);
>
>    type TUPLE is
>       record
>          -- ...
>          columns: Attributes.SET;
>       end record;
>    function compare(a, b: TUPLE) return BOOLEAN;
>    function hash(element: TUPLE) return Containers.HASH_TYPE;
>
>    package Tuples is new Containers.Hashed_Sets
>      (ELEMENT_TYPE => TUPLE,
>       hash => hash,
>       equivalent_elements => compare);
>
>    type TABLE is
>       record
>          -- ...
>          rows: Tuples.SET;
>       end record;
>    function compare(a, b: TABLE) return BOOLEAN;
>    function hash(element: TABLE) return Containers.HASH_TYPE;
>
>    package Tables is new Containers.Hashed_Sets
>      (ELEMENT_TYPE => TABLE,
>       Hash => hash,
>       equivalent_elements => compare);
>
>    type SCHEMA is
>       record
>          -- ...
>          relations: Tables.SET;
>       end record;
>
> end RDB2;

RDB2 looks good to me and is pretty close to what I had in mind.

I think I finally get what you were saying about inheritance.  Before
I posted the topic I was thinking about the design and I just wrote
down the "table is a collection" as part of sentence.  In my mind I
was thinking of a variable declaration:

table: collection;
tuple: collection;
schema: collection;

and so I posted my question.

Re: Generic Collection

[andrew]

Actually I take that back.  RDB2 looks promising with respect to how I
have my program now.  What I want is to be able to change my program
so that I can declare table, tuple and schema to be of a "collection"
type like:

table: collection;
tuple: collection;
schema: collection;

The collection would have to be a common object as in the sense of
Object in Java.  So here is an expanded pseudo-code example:

attr1 : attribute;
attr2 : attribute;
attr3 : attribute;

attr4 : attribute;
attr5 : attribute;
attr6 : attribute;

table1 : collection;
table1.add(attr1);
table1.add(attr2);
table1.add(attr3);

table2 : collection;
table2.add(attr4);
table2.add(attr5);
table2.add(attr6);

Or, if I had run a query where I projected attributes out of a table I
could use:

tuple : collection;

and fill it like I did the table.

Then, schema could be a collection of tables or tuples like:

schema : collection;
schema.add(table1);
schema.add(table2);

This again would depend on being able to use a common object like Java
has.

What do you think?

Re: Generic Collection

[Georg Bauhaus]

On Wed, 2007-05-09 at 07:51 -0700, andrew wrote:
> Actually I take that back.  RDB2 looks promising with respect to how I
> have my program now.  What I want is to be able to change my program
> so that I can declare table, tuple and schema to be of a "collection"
> type like:
> 
> table: collection;
> tuple: collection;
> schema: collection;

The question now becomes, do you want table, tuple, and schema
to have the same behavior? Then you could use instances of the
same generic collection package, or interface types, or mimick
duck types... Do you want table, tuple, and schema to be
interchangeable parameters for some "common" subprograms (other
than Add)?

Are there cases where you want your program to decide which
kind of collection it is reading?

> This again would depend on being able to use a common object like Java
> has.

Interestingly, Java has recently got generics. In part, because
this circumvents the consequences of everything being an Object.

> What do you think?

42 if your intent is to blur the distinction between tuple,
table, and schema to the extent that all have just one common
type; a reader of you program might then have to inspect quite
a bit of context to find out what is meant if something goes
wrong. If this is the case, can you show that the similarities
implied by Add and such should preclude any explicit distinction
between tuple, table, and schema?  OTOH, if they are Ada.Containers
all of them will have a similar interface, even though this fact
isn't reflected in an interface type.

Re: Generic Collection

[andrew]

On May 9, 11:12 am, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>
wrote:
> On Wed, 2007-05-09 at 07:51 -0700, andrew wrote:
> > Actually I take that back.  RDB2 looks promising with respect to how I
> > have my program now.  What I want is to be able to change my program
> > so that I can declare table, tuple and schema to be of a "collection"
> > type like:
>
> > table: collection;
> > tuple: collection;
> > schema: collection;
>
> The question now becomes, do you want table, tuple, and schema
> to have the same behavior? Then you could use instances of the
> same generic collection package, or interface types, or mimick
> duck types... Do you want table, tuple, and schema to be
> interchangeable parameters for some "common" subprograms (other
> than Add)?
>
> Are there cases where you want your program to decide which
> kind of collection it is reading?
>
> > This again would depend on being able to use a common object like Java
> > has.
>
> Interestingly, Java has recently got generics. In part, because
> this circumvents the consequences of everything being an Object.
>
> > What do you think?
>
> 42 if your intent is to blur the distinction between tuple,
> table, and schema to the extent that all have just one common
> type; a reader of you program might then have to inspect quite
> a bit of context to find out what is meant if something goes
> wrong. If this is the case, can you show that the similarities
> implied by Add and such should preclude any explicit distinction
> between tuple, table, and schema?  OTOH, if they are Ada.Containers
> all of them will have a similar interface, even though this fact
> isn't reflected in an interface type.

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.
Also, for that matter, anything stored in the collection would have to
extend (or possibly implement) a collection_object type.  Is that what
you were saying?

Re: Generic Collection

[Simon Wright]

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.

Re: Generic Collection

[andrew]

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.

Re: Generic Collection

[Georg Bauhaus]

On Thu, 2007-05-10 at 15:48 -0700, andrew wrote:
> On May 10, 2:31 pm, Simon Wright <simon.j.wri...@mac.com> wrote:

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

When is the type of the collection object determined? How?

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

This is an important question, if not the important question.
I'd try to answer it first.


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

If you want a collection that doesn't collect either Apples
or Oranges, but instead is capable of holding Apples, Oranges,
Cabbage, Motor_Oil, Whatever, you can have that, too. Is this
what you want?


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

Just think of the consequences of Java pre-1.5 collections delivering
nothing but Object objects.

Re: Generic Collection

[andrew]

On May 11, 3:10 am, Georg Bauhaus <bauh...@futureapps.de> wrote:
> On Thu, 2007-05-10 at 15:48 -0700, andrew wrote:
> > On May 10, 2:31 pm, Simon Wright <simon.j.wri...@mac.com> wrote:
> > > > 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.
>
> When is the type of the collection object determined? How?
The statement I made may be misleading.  It's not dispatching on the
type of the collection object but on the type of the object stored in
the collection.  Does that make better sense?


>
> > > Do you want to be able to add attributes to schemas? I would have
> > > thought not ..
>
> This is an important question, if not the important question.
> I'd try to answer it first.
It's irrelevant at this time.

> If you want a collection that doesn't collect either Apples
> or Oranges, but instead is capable of holding Apples, Oranges,
> Cabbage, Motor_Oil, Whatever, you can have that, too. Is this
> what you want?
Yes, but I wouldn't really be storing apples, oranges, cabbage, ... I
would be storing a common object type like "Object".  Right?


> > I don't understand why I would have run-time errors.  Please expand
> > that thought.
>
> Just think of the consequences of Java pre-1.5 collections delivering
> nothing but Object objects.
There was a problem with delivering objects of type Object?

Re: Generic Collection

[Georg Bauhaus]

On Fri, 2007-05-11 at 13:41 -0700, andrew wrote:
> On May 11, 3:10 am, Georg Bauhaus <bauh...@futureapps.de> wrote:
> > On Thu, 2007-05-10 at 15:48 -0700, andrew wrote:
> > > On May 10, 2:31 pm, Simon Wright <simon.j.wri...@mac.com> wrote:
> > > > > 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.
> >
> > When is the type of the collection object determined? How?
> The statement I made may be misleading.  It's not dispatching on the
> type of the collection object but on the type of the object stored in
> the collection.  Does that make better sense?

OK.

tuples: collection;
tables: collection;

declare
 item: ? := get(tables, key);

If you don't care that there is only one type of collection for
all kinds of objects, then indeed references to DB_thing'class
objects seem a plausible choice for storing table objects in
collection. Where

   type DB_thing is abstract tagged private;
   type DB_thing_ref is access DB_thing'class;

   type attribute is new DB_thing with private;
   type tuple is new DB_thing with private; 
   ...

   package DB_collections is new Containers.Hashed_Sets
      (Element_Type => DB_thing_ref, ...);

   subtype collection is DB_collections.Set;

Is there really a sufficiently common algorithm for schemas,
tables, tuples, and attributes?


> > If you want a collection that doesn't collect either Apples
> > or Oranges, but instead is capable of holding Apples, Oranges,
> > Cabbage, Motor_Oil, Whatever, you can have that, too. Is this
> > what you want?
> Yes, but I wouldn't really be storing apples, oranges, cabbage, ... I
> would be storing a common object type like "Object".  Right?

Right.


> > > I don't understand why I would have run-time errors.  Please expand
> > > that thought.
> >
> > Just think of the consequences of Java pre-1.5 collections delivering
> > nothing but Object objects.
> There was a problem with delivering objects of type Object?

Yes, there was a problem with everything being of type Object.
For example, retrieving references from collections forces
type checking at run time and throwing ClassCastException
when there is a mismatch.
    some_ref = (IKnowWhatType) container.get(some_key);
That is a reason why Java now has generics.

Re: Generic Collection

[andrew]

On May 11, 4:28 pm, Georg Bauhaus <bauh...@futureapps.de> wrote:
> If you don't care that there is only one type of collection for
> all kinds of objects, then indeed references to DB_thing'class
> objects seem a plausible choice for storing table objects in
> collection. Where
>
>    type DB_thing is abstract tagged private;
>    type DB_thing_ref is access DB_thing'class;
>
>    type attribute is new DB_thing with private;
>    type tuple is new DB_thing with private;
>    ...
>
>    package DB_collections is new Containers.Hashed_Sets
>       (Element_Type => DB_thing_ref, ...);
>
>    subtype collection is DB_collections.Set;
I'm going to have to look at this more.  So far it looks promising.


> Is there really a sufficiently common algorithm for schemas,
> tables, tuples, and attributes?
add, remove, getnext, find, sort, search, etcetera.  So yeah, the
basic collection of things type of operations.


> > > > I don't understand why I would have run-time errors.  Please expand
> > > > that thought.
>
> > > Just think of the consequences of Java pre-1.5 collections delivering
> > > nothing but Object objects.
> > There was a problem with delivering objects of type Object?
>
> Yes, there was a problem with everything being of type Object.
> For example, retrieving references from collections forces
> type checking at run time and throwing ClassCastException
> when there is a mismatch.
>     some_ref = (IKnowWhatType) container.get(some_key);
> That is a reason why Java now has generics.
OOOHHHHH, that...shoot, you had me going there for a minute.  I
thought it was something _serious_ that somehow is related to a
problem that Ada would have.

Re: Generic Collection

[Simon Wright]

andrew <andrew.carroll@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.

Re: Generic Collection

[Dmitry A. Kazakov]

On Sat, 12 May 2007 08:18:09 +0100, Simon Wright wrote:

> andrew <andrew.carroll@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);

+ some other set-theoretic operations on the containers.

You meant

   procedure Add (To : in out Table; Item : Tuples.Tuple'Class);

of course.

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

The problem is not in checks but with the design. The code reader has no
idea of what can be done with a collection member <=> what to expect there
<=> what can be put there. The algebra of collections does not tell
anything about that (= about the meanings of tuples and the sets of). It is
not yet a design.

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

Uhm, class-wide programming above is rather about implementation of
containers in a manner independent on what is in. This does not contradict
in any way to problem solving, which presumes doing something with the
things in the containers. These are just two different problems. So as long
as nobody says anything about what should be done with tuples, we assume
that it must be nothing. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Generic Collection

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> 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);
>
> + some other set-theoretic operations on the containers.
>
> You meant
>
>    procedure Add (To : in out Table; Item : Tuples.Tuple'Class);
>
> of course.

Did I? Not if Tuple isn't (visibly) tagged. Why would I make it
tagged? (I don't see anything in the application use cases so far (!)
to say it should be).

If your implementation guidelines say that everything should be tagged
I'd have to ask why? (I don't believe that programming-language
inheritance is necessarily a good way of implementing application area
specialization/generalization).

>> 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.
>
> The problem is not in checks but with the design. The code reader
> has no idea of what can be done with a collection member <=> what to
> expect there <=> what can be put there. The algebra of collections
> does not tell anything about that (= about the meanings of tuples
> and the sets of). It is not yet a design.

I think we are probably agreeing here. In general
collections/containers are part of the implementation, not part of the
application; I don't think I've ever found a case where it would have
been right to show an application-level concept like Table as being
visibly a container.

>> 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.
>
> Uhm, class-wide programming above is rather about implementation of
> containers in a manner independent on what is in. This does not
> contradict in any way to problem solving, which presumes doing
> something with the things in the containers. These are just two
> different problems. So as long as nobody says anything about what
> should be done with tuples, we assume that it must be nothing. (:-))

I guess I expressed myself badly there. I was trying to make the point
I've just made above.

Re: Generic Collection

[Dmitry A. Kazakov]

On Sun, 13 May 2007 12:00:58 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>> 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);
>>
>> + some other set-theoretic operations on the containers.
>>
>> You meant
>>
>>    procedure Add (To : in out Table; Item : Tuples.Tuple'Class);
>>
>> of course.
> 
> Did I? Not if Tuple isn't (visibly) tagged. Why would I make it
> tagged?

No, the package in question does not define Tuple. That means that Add will
not be a primitive operation of. Consequently Add is declared to work with
any Tuple, per design. To me it is class-wide. This is independent on
whether Tuple is tagged or not. After all one can derive from non-tagged
types.

> (I don't see anything in the application use cases so far (!)
> to say it should be).

Yes, but that is the problem with the whole idea. However, what about
function "=" (Left, Right : Tuple) return Boolean?

> If your implementation guidelines say that everything should be tagged

Probably yes, I am not certain about this issue. But not in the present
Ada, which has tagging overhead and no multiple dispatch.

BTW, this is why everything should better be "tagged" (in the sense of
having T'Class), just to be relieved of making such choices. A comparable
case is generics. Any type can potentially be an actual for "type T(<>) is
limited private;" So, any type is in the generic class "(<>) limited
private." Why 'Class should be discriminated?

> I'd have to ask why? (I don't believe that programming-language
> inheritance is necessarily a good way of implementing application area
> specialization/generalization).

That could be, but so far there is no great alternative mechanisms for
that. Other types of polymorphism are supported by generics and
overloading. Neither of them really shines.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Generic Collection

[andrew]

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.

Re: Generic Collection

[Simon Wright]

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

Re: Generic Collection

[Randy Brukardt]

"Simon Wright" <simon.j.wright@mac.com> wrote in message
news:m2tzuh0yz9.fsf@mac.com...
....
> If your implementation guidelines say that everything should be tagged
> I'd have to ask why? (I don't believe that programming-language
> inheritance is necessarily a good way of implementing application area
> specialization/generalization).

Not to speak for others, but there are a lot of reasons:

(1) Most complex types need to be controlled in order to properly manage
their memory. Making them visibly tagged thus has no overhead.

(2) Maximum flexibility: allowing future clients the ability to extend the
type without modifying the base type likely reduces future maintence (can't
break something that you don't change). I don't care much for or about
inheritance, but extension is a big win.

(3) Tagged types "work right" in Ada: "=" composes properly, user-defined
operations are used in generics (not true for untagged types, where the
predefined ones "reimerge"), parameter passing is consistent;
'Access can be used in the implementation without forcing users to declare
everything in sight aliased, you can use prefix calls on the objects, and
there may be more that I've forgotten.

Note that none of these have anything to do with classwide programming,
dynamic dispatching, or inheritance, or in fact the tag itself. (3) was an
important enough issue that we actually considered adding an "aliased" type
to the Amendment which would provide those benefits without requiring a tag.
But in the end it was considered to be not enough of an improvement.

Conclusion: (almost) all new ADTs in Ada should be visibly tagged and
possibly visibly derived from Controlled.

                              Randy.

Re: Generic Collection

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon.j.wright@mac.com> wrote in message
> news:m2tzuh0yz9.fsf@mac.com...
> ....
>> If your implementation guidelines say that everything should be tagged
>> I'd have to ask why? (I don't believe that programming-language
>> inheritance is necessarily a good way of implementing application area
>> specialization/generalization).
>
> Not to speak for others, but there are a lot of reasons:
>
> (1) Most complex types need to be controlled in order to properly manage
> their memory. Making them visibly tagged thus has no overhead.
>
> (2) Maximum flexibility: allowing future clients the ability to extend the
> type without modifying the base type likely reduces future maintence (can't
> break something that you don't change). I don't care much for or about
> inheritance, but extension is a big win.
>
> (3) Tagged types "work right" in Ada: "=" composes properly, user-defined
> operations are used in generics (not true for untagged types, where the
> predefined ones "reimerge"), parameter passing is consistent;
> 'Access can be used in the implementation without forcing users to declare
> everything in sight aliased, you can use prefix calls on the objects, and
> there may be more that I've forgotten.
>
> Note that none of these have anything to do with classwide programming,
> dynamic dispatching, or inheritance, or in fact the tag itself. (3) was an
> important enough issue that we actually considered adding an "aliased" type
> to the Amendment which would provide those benefits without requiring a tag.
> But in the end it was considered to be not enough of an improvement.
>
> Conclusion: (almost) all new ADTs in Ada should be visibly tagged and
> possibly visibly derived from Controlled.

Thanks for that. Those are all reasonable reasons (possible exception
of (2); application ADTs tend not to have 'clients', I'd have thought,
in the sense that you'd want to support unforeseen extensions? And I
can probably break something in strange ways by bad overridings.
Framework ADTs, on the other hand, are of course there to be extended).

It's a shame that untagged types don't "work right" in Ada :-)

Untagged types don't work right - was: Generic Collection

[Grein, Christoph (Fa. ESG)]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> (3) Tagged types "work right" in Ada: "=" composes properly,
user-defined
> operations are used in generics (not true for untagged types, where
the
> predefined ones "reimerge"), ...

There is a reason why untagged types don't work right, compatibility to
Ada 83 (AARM 4.5.2(24.a).

See here if you want to know more ;-)

<http://www.christ-usch-grein.homepage.t-online.de/AdaMagica/Dead.html>


Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt

CONFIDENTIALITY NOTICE 

This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 

Re: Generic Collection

[Benjamin Place]

On 5/15/07, Randy Brukardt <randy@rrsoftware.com> wrote:
>
> Conclusion: (almost) all new ADTs in Ada should be visibly tagged and
> possibly visibly derived from Controlled.

That echoes Prof. Dewar's recommendation in the graduate programming
languages (IIRC) class at NYU.

Always nice to see the gurus in agreement.

Best,
Ben