--- Sam Vilain <[EMAIL PROTECTED]> wrote: > 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.
Are you speaking in terms of limitation, or requirement? It would be nice to have a syntax solution. I've seen p5 interfaces with stubs that die so that you have to override them in a subclass. It works, but seems a little kludgy. And I'm coming in late on this. Are you saying you want Exporter/%EXPORT_TAGS functionality built into the language and into all objects? Wouldn't that jack up the overhead? Is that what you mean by "associations", below? It seems like a pretty generic word. > 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 :-). lol -- probably. :) But did you say that right? "MI should be frowned upon where Interfaces will not do"? Or are you using interfaces as a form of MI? I tend to think of them (inaccurately, I suppose) as "not really inheriting", but just defining requirements. Java pollution, probably. ;o] But I think it is generally frowned upon, while not being officially _bad_. We musn't dictate style. I prefer delegation, and making better ways available discourages the effectively deprecated methodology, but sometimes one needs to use what one knows and get the job done. As much as I dislike it, I have to admit that there are times to apply the adage "if a jobs worth doing, it's worth doing poorly." Then again, there are folk who will argue that MI isn't doing it poorly. For some problems, it might be the most elegant solution, even if interfaces won't handle the situation. An interface really *isn't* a true inheritance, after all -- so there must be a reason there's a difference. :o} > 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. Sounds like MI. > 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. LOL!! (My ex and I once made 40-garlic Chicken Felice. Our classrooms *reeked* the next day, and the students were dying, but it took me all day to figure out why they were SO miserable, and I couldn't smell anything at all!! :) > Leave them out to carry on with the status quo of a myriad of subtly > different, non-interchangable approaches to associating classes. TMTOWTDI? Still, though your point is valid if I understand it, it will always be possible to create "non-interchangable approaches", and we don't want to dictate methods if we can help it. I think I need an example....unfortunately I'm at work and haven't the time to properly peruse the one you offered. Thus I must apologize, and wait for more input. Paul __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
