Rod Adams <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>Discussion seems to have went off into esoteric cases of locally
>>overriden dispatcher policies and what not.
> I don't think it's as esoteric as you might think. Consider:
> package Foo;
> use MMD::Random;
> our &bar is MMD::Random is export(DEFAULT);
> multi sub bar ($x) {...};
> multi sub bar ($x) {...};
> Note that they all have the same signature. The Manhattan policy would
> complain about this, since it's looking for the closest parameter match.
> The Random policy does not care. It's going to randomly pick any member
> method for each call.
Ok. If you'd really need such random dispatch, it could be done like
this, when I interpret A12 correctly:
sub run_random_bar($x) {
my @meths = WALKMETH($x, :method('bar'));
my $meth = @meths[rand(@meths.elems)];
$meth($x);
}
or even with
my sub bar($x) {...} # same body as above
bar($x);
If you need an esoteric dispatcher roll your own :)
> Since the main goal of treating multis as an object was to be able to
> override the dispatch policy, I think how a user defined policy
> interacts with different localities is very much on topic.
I don't think that the policy should be in the MultiSub object. You have
all methods and information to be able to do your own dispatch, if
needed. Your approach would very likely disable all possible
optimizations.
Anyway, that's far future.
>>What I'd like to know is more basic things:
Yes, still :-)
>>1) is there a MultiSub object with one short name that holds all
>>possible long names (and function references)?
>>
>>
> As for whether such a thing is visible at the Perl level, I think that
> depends on if we allow user defined dispatch policies or not. If not,
> it's just an introspection tool that could be addressed in other ways.
Don't think so. It's a problem of namespaces and how these multi subs
are managed. It touches Perl6 as well as Parrot.
> Even without custom policies, p6c may decide to go the MultiSub object
> route at the compiler level. But I can't speak to that, nor on the
> Compiler <-> Parrot interaction.
It depends on what Parrot will get from the Perl6 compiler.
>>What about multi subs? They can be defined everywhere. Given:
>>
>> multi sub *foo(A $a, B $b) {...}
>>
>>Is this something like:
>>
>> %globals{"foo"} --> MultiSub{"foo_A_B" => Sub, ...}
>>
>>What about a not so global multi:
>>
>> multi sub foo(A $a, B $b) {...}
>>
>>
> This can be seen as questioning how to keep track of what multi's are in
> scope at any given point in time, because you must dispatch amongst all
> the multi's visible, regardless of the differing scope.
Sure. But the dispatch scheme is described in A12. That is per se not
the problem.
> However if you have multi's from a mix of different sources and scopes,
> all with the same short name, which policy decides how to dispatch
> amongst them at a given calling locality is very much at issue, and is
> roughly where we are in the discussion.
Yes. The policy will be handled by a dispatcher object's dispatch
vtable, as far as I can currently see.
leo
