--- Andy Wardley <[EMAIL PROTECTED]> wrote: > 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.
Agreed. Is there any reason that shouldb't be done with something like use Associasions; associate( $foo => $bar, @opts ); # opts defining association type I see no real desperate need for that to be an integrally linguistic mechanism, tho perhaps I'm being dense again. Seems to me a module could do all that was needed, in p5 and/or p6. > 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. Easy enough for a module to keep and internal doubly-linked list of objects that describe the relationships of things it has been told to attend. > 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. So the relation object for any given registered object could have subtrees that identify all these. It seems simple. Am I missing something? > 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. Sensible, and still reasonably easy to implement.... > 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. :-) hmm... maybe not. Inheritance is an assosiation of sorts, isn't it? (please don't let that open another can of worms, lol...) But the child object knows it's parent, and can inherit methods and atributes, while the parent can know nothing about it's child in standard OOP structure. That's an inconsistent assosiation, isn't it? I only mention it because, though I can't really think of a good example of when it would be needed, I'd hate to say you can't *have* one, just because.... Easier to code and maintain for flexibility from the start. :) > 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). But I *LIKE* quantum mechanical chicanery! >:O} Still, I concur. The object shouldn't need to know or care who else "owns" it. My coffee cup doesn't. But if the program needs to identify whose coffee cup it is, there should be a way. The Cup object shouldn't be required to have an owner attribute dictated by a theoretical Association system in the language. Many applications, most, I'd say, won't need it, and I'd rather skip the overhead. If I need it, I'll pull in the necessary module and set up the relationships as required. Now it *would* be nice if the Association module could help shortcut that and provide some syntactic sweetener, but for that I don't even mind if it's Aspartame. ;o] > 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. I must admit I like this idea -- it's *feels* elegant, but I have no idea off the top of my head how you would *use* it. Can you give me an implementation example, in theoretical code? > 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. Maybe. I'm almost convinced, but I need to see more concrete examples. __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
