Re: ?Re: Re: ?Re: RFC: Class::DispatchToAll

[frag]

I don't think I explained myself well, or else I'm not understanding your criticism. I am talking about calling a set of methods from parent classes, taking the results, and deciding whether or not to call the next. (domm's module doesn't do this checking, but it wouldn't be hard to incorporate it. In any case, in this sort of design you must take into account the possibility that all the parental methods would be invoked anyway.) It's set up so that this is only true for a given, fixed set of functions; functions that can be clearly traced back in the code. (These functions are also documented thoroughly and are vetted to be free of side-effects upon non-localized data. I agree with you about the importance of discipline in OOP.) It seems to me that this actually solves one of the major multiple inheritance headaches, by designating a method in the child class that acts as a wrapper for all of the parental methods that attempt the same function.

Note that I misspoke in my earlier comment about wrapper methods; essentially, that's all this is, dispatch being controlled and monitored by a single method. You've got a generic wrapper method in the child class that takes the names of the parental methods that it should handle. This does not vary at run-time, but is a constant within the child class that is handling the dispatch.

Also please note that I am not arguing that multiple inheritance is some sort of no-brainer to be used cavalierly. I am saying that I have found a particular situation where I think it makes sense. I don't question that this is a single solution to a limited set of problems.

Finally, I have to admit that I just don't see that NEXT is always the best approach. NEXT allows each method in the parent class to make its own decisions about whether to continue dispatch or not. But it seems more natural to me, and safer, even, to have a central method oversee the process.

-- Frag.
--
"It's beat time, it's hop time, it's monk time!"