Leopold Toetsch wrote:
Rod Adams <[EMAIL PROTECTED]> wrote:I sounds like a good plan, as long as it works. However, I'd want to create the "sub" at the same scope (most likely class/package) as the "multi sub"s with the same name. I'm presently not clear if that's allowable. If I have to create a lexical method in each user to dispatch to my class, that seems sub optimal. I prefer to stick with .bar vs ._bar
If I were to need a different policy for a given method .bar, I wouldNot necessarily, AFAIK. You can define a lexical "sub bar", which hides
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.
all outer multi subs. This "bar" can be used to dispatch to the multi
subs.
Consider the case where I wish to create several multi's with significantly different signatures, but you write each one twice, once with an "is debug" trait, and once with an "is operational" trait. I would have some runtime signal to determine if I need to be running the debug versions, or the operational versions.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 :)
If you put too much onus on the caller function to get the call correct, you might as well just name all the methods something different and forget about MMD altogether.
... 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].
Currently you are likely correct. I was proposing to change that.
The current dispatcher has to collect a list of possible candidates fromI was offering the ability to change which policy does the decisions, after collecting the candidates.
all the possible multis, and then decide, depending on the policy, which
sub should actually be called.
So you're saying that if I create a multi with the same scope and long name as a preexisting multi, that old multi will still be around in memory, even though it could never be called without a custom dispatcher?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.
I was under the impression that defining two multi's with the same long name in the same scope clobbered one of the involved parties and triggered a redefinition warning.
I was imagining dispatching based off the C< want > function, which I have no idea how it will be implemented at the Parrot level, but it's a defined part of Perl.... 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.
Of course.
A trait added to an object instance creates an anonymous subclass, certainly.
... 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.
But I didn't think that adding a trait to a member of a class created a new subclass...
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,
`-------------------------------------------------------------------------
Indeed, that is the current case.
But it's a language issue as to whether we want the compiler to allow two identical "long names" or not.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.
If a MultiSub with that short name already exists, you follow it's policy. If not, you create a new MultiSub with whatever policy is default to the current scope.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.
=========
Overall, I've come to the following conclusion:
- We are sacrificing some capabilities by not having user defined MMD.
- However, the utility of those capabilities does not merit the effort it would take to implement in 6.0.
- We should, however, leave the door open for 6.x to allow such things with as little pain as possible.
So I'm dropping this thread.
-- Rod Adams
