On Wed, 05 Mar 2003 13:31, Brent Dax wrote: > # *) A superclass (obviously, but I consider it to be the > # same level as > # Properties, Methods and Attributes.) > Superclass*es*. Perl 5 has MI, and I don't expect that to change in > Perl 6. Parrot absolutely *must* support Perl, or it has failed in its > primary goal. > # *) a set of Interfaces (similar to multiple inheritance; a way of > # grouping methods associated with a class for another to > # implement). > # eg, in Java and IDL. > Can this be implemented in terms of MI and/or delegation? (For Perl 6's > part, my understanding is that an interface is just a class that > inherits from Interface--although I could *easily* be wrong about that.)
Whether to implement interfaces using Multiple Inheritance, or Multiple Inheritance using Interfaces is a half empty/half full decision. It makes little difference. What I'm saying is that it should be possible to `filter' which methods you inherit via @ISA. Ideally there would be some standard way for a module to describe groups of methods for other classes to import a la Exporter's %EXPORT_TAGS. The result would allow both Multiple Inheritance *and* Interfaces. In my experience classes only have *is a* relationships with one other class. The other classes they inherit are *can behave like a* relationships. MI should be frowned upon where Interfaces will not do IMHO. But that is a flamewar topic :-). > # *) Associations, eg in UML. > I've deleted your stuff about associations below, which described their > properties nicely, but didn't explain what they *are*. What are they > and when would you use them? Can they be implemented in terms of > properties and/or attributes? Associations are grouping two classes together. Or more, in the general case, but this is not required as three way associations can be broken down into an `association class' with three or more two way associations. It is a simple concept. You use them all the time, whether you call them associations or not. When I first started recognising them after I started to learn UML, programming felt like cooking with Garlic for the first time. For instance, a biological parent/child relationship is a two to many association. From the parent's angle, the association might be called `children'. From the child's angle, the association might be called `parents'. They are the same relationship, and altering one should affect the other - this `empathic' effect of the collections is (IMHO) important to include. It's a bit like declaring a linked list and not having to worry about maintaining both directions in your user code. In RDBMS terms, a many to one relationship is implemented with an `id' column in the referring class. A one to many relationship is implemented with a `foreign key' in the referant class. Is the relationship from the class with the foreign key to the class without or the other way? It is both. Associations can be implemented in terms of properties and/or attributes, however I think it would pay to have a common way to access and manipulate the collections that implement the associations, so a piece of code can decline to care whether it is a `many to one' relationship implemented with a simple reference, an `ordered' relationship implemented with a array, an `unordered' relationship implemenetd with a set or bag, or a `keyed' relationship implemented with a hash. In fact, I have implemented such behaviour using attributes, in Class::Tangram - an experimental pre-release (for Perl 5 :)) is available at: http://vilain.net/pm/Class-Tangram-1.12.2.tar.gz Probably the most relevant for this discussion are the README and t/04-containers.t. It is not yet complete, I need to flesh the test cases out more. Right now the implementation of this particular feature leaves a bit to be desired (it's still in the `code it slowly but correctly' stage), which is why I haven't released it to CPAN yet; the real drawback right now for me is speed. I'm working on some alternatives which would be faster (see README.Containers in the distribution). Associations could easily be left out of the object core if it is not deemed to fit; but I just thought I'd say that I consider these to be one of the primary elements of objects and so IMHO belong in the Perl 6 object implementation. UML considers them pretty core, too. Leave them out to carry on with the status quo of a myriad of subtly different, non-interchangable approaches to associating classes. -- Sam Vilain, [EMAIL PROTECTED] If you think the United States has stood still, who built the largest shopping center in the world? RICHARD M NIXON
