develooper Front page | perl.perl6.language | Postings from March 2005

Re: MMD as an object.

Thread Previous | Thread Next
From:
Leopold Toetsch
Date:
March 11, 2005 07:06
Subject:
Re: MMD as an object.
Message ID:
200503111409.j2BE9fZ26848@thu8.leo.home
Rod Adams <rod@rodadams.net> 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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About