Sam Vilain wrote:
>Associations *are* fundamental object things. Presenting them in terms of
>attributes is the real hack.
Associations *are* fundamental things, but I don't think they are part
of an object.
They describe relationships between objects and should exist independantly
and orthogonal to them.
Dave Whipp wrote:
> An association is a mechanism that permits one object to navgigate to
> another. If the association is bidirectional, then it is possible to
> also navigate from the target back to the source. Each direction of
> navigation should be given a unique identifer.
Category theory has something to say about this. I hope I can provide
an essence of it, despite my limited understanding of the subject...
A category is defined by a collection of elements (objects in this case)
and a number of morphisms (relations) that provide mappings between the
different elements.
There are many different kinds of morphisms: epimorphisms (one-to-),
monomorphisms (-to-one), isomorphisms (one-to-one), polymorphisms
(-to-many) and so on. In category theory, morphisms are dual,
so that for each relationship represented by an arrow between two
objects, there is a reciprocal relationship travelling back down the
arrow in the opposite direction.
Traditional databases and object systems are based on set theory. Set
theory is in fact just one kind of theory that is described by category
theory (think of Category Theory as a class and Set Theory as an instance).
The category morphisms that are defined by set theory are 'identity' and
'contains' (insert general paraphrasing and hand-waving warning here).
The 'identity' isomorphism gives each element in the set a unique identifier
so that you know which one you're talking about at any time. 'contains'
is a polymorphism that defines which elements are contained by which other
elements.
If you want to make it an ordered set, then you need to add another
morphism, 'before' (and its dual morphism 'after') which tells you
which of any two elements in a set is ordered before the other.
If you want to make a tuple, hash, queue, stack, bag, stream or
multi-coloured, cross-referenced, hyper-indexed, double-camel Larry
space in 9 + 3i dimensions, then you just need to add a few more
morphisms that define those extra relations that are characteristic of
that kind of information space.
In summary:
Category == [ Elements, Morphisms ] # math terminology
== [ Objects, Associations ] # programming
== [ Records, Relations ] # database
> An association is either "consitant", or "inconsitant".
I think it is better to assume that there is no such thing as an
inconsistent morphism. If the shoe doesn't fit, then don't wear it!
Find another shoe or go barefoot. :-)
> While it it is obvious that associations can be implemented using
> attributes, it seems to me that, to do so, is [ ...not so good... ]
Agreed. Associations are no more part of an object than an electric
current is part of an electron. The field is defined by the interaction
between fundamental particles but is not an inherent part of the particles
themselves (wave/particle duality and other quantum mechanical chicanery
aside).
The only reason that we are currently forced to use attributes to represent
our relations is because our OO systems and databases are based on set
theory. An object or database record is conceptually nothing more than
a set containing attributes. We define relations using attributes as
foreign keys because there's no other way to do it.
If instead we borrow the conceptual model from category theory and
provide a mechanism for defining elements and relations *separately*,
then it should be possible to build all kinds of fancy information
spaces with any number of different inter-element relationships defined.
The only language that I'm aware of that implements something like this
is CAML (although I'm sure there must be others).
Reading from http://caml.inria.fr/ercim.html :
"It is possible to define a type of collections parameterized by the
type of the elements, and functions operating over such collections.
For instance, the sorting procedure for arrays is defined for any
array, regardless of the type of its elements."
Anyway, the gist of this long rambling post is that In My Humble Opinion,
if Perl 6 is to provide the ability to define associations between objects,
then it should do so as part of a larger category mechanism rather than
as an extension to the class/object mechanism.
A
