Front page | perl.perl6.language |
Postings from March 2005
Re: MMD as an object.
Thread Previous
|
Thread Next
From:
Rod Adams
Date:
March 11, 2005 12:55
Subject:
Re: MMD as an object.
Message ID:
423205AA.9030202@rodadams.net
Leopold Toetsch wrote:
>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.
>
>
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
>>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 :)
>
>
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.
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 from
>all the possible multis, and then decide, depending on the policy, which
>sub should actually be called.
>
>
I was offering the ability to change which policy does the decisions,
after collecting the candidates.
>>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.
>
>
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?
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.
>>... 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.
>
>
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.
>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.
>
>
>>... 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.
>
>
A trait added to an object instance creates an anonymous subclass,
certainly.
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.
>>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.
>
>
But it's a language issue as to whether we want the compiler to allow
two identical "long names" or not.
>>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.
>
>
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.
=========
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
Thread Previous
|
Thread Next