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