Rod Adams <[EMAIL PROTECTED]> wrote: > If I were to need a different policy for a given method .bar, I would > likely create something called .bar much like your "run_random_bar", > which then dispatches amongst methods I name something like ._bar .
> I see some detractions to this approach: > 1) Users wishing to add another multi to the mix must know that they > have to make it a ._bar instead of a .bar. Not necessarily, AFAIK. You can define a lexical "sub bar", which hides all outer multi subs. This "bar" can be used to dispatch to the multi subs. > 2) What parameter signature do you give the wrapper method, so it does > not clobber the arguments, yet still has them to pass on to the > appropriate method? And at the same time, determine what signature the > wrapper was called with, to determine who to dispatch to... Well, I presume, if you are writing such code, i.e. a bunch of mutli subs with the same signature, you are very well aware of what you are doing. So you'll know, how you call the dispatcher (and what funny effects you'll yield :) >... I hadn't > said it before, but I had assumed the dispatch method of the MultiSub > would have a signature of something like "Str @types" passed to it. I don't thing that the MultiSub does dispatch nor that it has a dispatch method. The MultiSub object is just a collection of multi Sub candidates for one of the scopes [lexical, package/module/class, global, builtin]. The current dispatcher has to collect a list of possible candidates from all the possible multis, and then decide, depending on the policy, which sub should actually be called. > 3) It does not allow more than one sub with the same signature and short > name to be in scope at the same time. That's mainly a Perl6 compiler problem. When the MultiSub is just a list of candidates, you can append whatever signature you like. There is no check for duplicates. It's only the dispatcher that will detect ambiguous signatures, if it cares about, like the default dispatcher. > ... For instance, dispatching based on return > type. Well, while there is a symmetry in call and return, when Parrot is concerned, dispatching on return types isn't easy, or better, it could just be done for the total static case, where all return results are known beforehand. For that case you could just call different subs in the first case. If the return type is just the runtime result, after the sub is run, you can do nothing in the dispatcher, which long before had called the sub. > ... Or off of some user defined trait the different methods have. Or > the most common case: on named arguments. A trait creates usually an anonymous subclass of the involved class and therefore has precedence over a not so specific class. MMD on named arguments isn't specified yet, or: ,--[ A12 ]---------------------------------------------------------------- | It is not likely that Perl 6.0.0 will support multiple dispatch on named | arguments, `------------------------------------------------------------------------- > My understanding of the P6 Long Names is that if one creates a multi > with the same parameter signature as a previously defined multi of same > short name, it masks the previous one if in a tighter scope, or erases > the previous if the same scope. As said, that's mainly a Perl6 compiler problem. The compiler can't emit two identical "long names" as one of these wouldn't be callabale then. > The original thought was to have the policy take over the acceptance of > new multi's into the MultiSub as well as taking over dispatch, thus > allowing for such flexibilities. What policy is in effect, if you define somewhere a "multi sub"? I think, that can't work. > And quite likely, the policy itself would not be in the MultiSub, but > the MultiSub would have a reference to which policy it's using. No, I don't think so. The current (lexical) scope has the policy, according to A12. > Some of the management issues I see that need addressing are: [ good questions for the compiler folks ] leo
