Re: Generic Package

[Georg Bauhaus <bauhaus@futureapps.de>]

On Thu, 2007-04-26 at 08:31 -0700, andrew.carroll@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. :)