Associations *are* fundamental object things. Presenting them in terms of attributes is the real hack.
I agree with this statement; and Brent previously asked what associations *are*. The problem with describing them in terms of attributes/properties not not so much that its a hack, but that its an implementation. I'd like to attept to define what associations are, and then work out if attrubutes are the most appropriate representation within Perl6.
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.
An association has an associated multiplicity. This is usually defined as either "one" or "many", with zero either permitted or excluded.
When the multiplicity is "many", then the order of navigation becomes an issue. This would typically be either "orderd" or "unordered"; in addition, we may wish to ensure uniqueness. Ordering my be either the order in which targets were added; arbitrary, or sorted.
An association may be thought of as a list/set/bag of pairs. Each pair is an instance of the relationship. If the pair is, itself, and object: then it can have additional attributes/methods that characterize the instance of the association. An example might be to record a timestamp of then the association was made.
An association is either "consitant", or "inconsitant". A consitant association is one where the number of associated targets is consistant with the multiplicity defined for the association. While building/modifying assemplies of objects, it is often necessary/useful to have an inconsitant association (e.g. a 1:1 association will be inconsitant for a short period, if one object is created before the other). If an inconsitant association is navigated, then results may be garbage. Such navigation could trigger an exception; or, in a threaded environment, block until the association is consitant.
It is possible to define associations that do not require objects to be linked/unlinked. Such associations must be "formalized". Formalization defines the association in terms of values of attributes. The association then becomes as equivalence relation. For example, if a "Teacher" object has a name; and a "pupil" object has a "teacher's name" attribute, then the association can be formalised as "$teacher.name == $pupil.teacher_name". The the attribute is a actually a method, then these relationships can become very dynamic. Relational databases usually use formalized associations: "$obj1.id == $obj2.foreign_key".
I've probably missed some important properties, but this should be enough for discussion. Whilst it is obvious that associations can be implemented using attributes, it seems to me that, to do so, is a bit like implemented a "while" loop using "if" and "goto". The opposite extreme: implementing attributes as associations, is also inappropriate. My thinking is that associations should be defined in much the same was as classes:
class Assoc1
is association(
Type1 $source,
Type2 @target is sorted { $^a cmp $^b } is unique
)
{
...
}#later my @type2_objs = $type1_obj.target;
(Or perhaps the Perl5 arrow syntax would be more appropriate here).
Dave.
