Multisubs and multimethods: what's the difference?
Joshua Choi
What's the difference between
multi sub infix:<..> ( Int $min, Int $max ) { ... }
and
multi method infix:<..> ( Int $min, Int $max ) { ... }
?
And in the case there isn't one, what's the point of declaring if it's a
"sub" or "method"; why not just "multi" or something? Surely there won't
be multirules, multimacros, etc. Right?
Thanks to all,
Joshua Choi
Larry Wall
: Kudos to all the Perl 6 mailing list.
Not to mention all the people on the list... :-)
: What's the difference between
: multi sub infix:<..> ( Int $min, Int $max ) { ... }
: and
: multi method infix:<..> ( Int $min, Int $max ) { ... }
: ?
A multi sub presents only an MMD interface, while a multi method presents
both MMD and SMD interfaces. In this case, there's not much point in the
SMD inteface since .. used as infix is always going to call the MMD interface.
: And in the case there isn't one, what's the point of declaring if it's a
: "sub" or "method"; why not just "multi" or something? Surely there won't
: be multirules, multimacros, etc. Right?
If you just say "multi" it defaults to "multi sub". We can theoretically
have "multi rule" if you declare parameterized rules, though most rules
take the same argument list. A set of "multi macro" would presumably
dispatch at compile time, but it's not clear how the various "is parsed"
rules would interact.
Larry
Jonathan Lang
> A multi sub presents only an MMD interface, while a multi method presents
> both MMD and SMD interfaces. In this case, there's not much point in the
> SMD inteface since .. used as infix is always going to call the MMD interface.
So:
multi method : MMD and SMD
multi sub: MMD only
method: SMD only
sub: no dispatching
right?
And just so that it's clear: when you talk about the SMD interface,
you're talking about being able to say "$var.foo" instead of "foo
$var", right? Whereas MMD doesn't have any special calling syntax.
Otherwise, the only difference between MMD and SMD would be the number
of arguments that are used for dispatching purposes (all of them vs.
just the first one).
Can subs be declared within classes? Can methods be declared without
classes? If the answers to both of these questions are "no", then it
occurs to me that you _could_ unify the two under a single name, using
the class boundary as the distinguishing factor (e.g., a method is
merely a sub declared within a class). If the answer to either is
"yes", I'd be curious to know how it would work.
--
Jonathan "Dataweaver" Lang
Stevan Little
> Can subs be declared within classes? Can methods be declared without
> classes? If the answers to both of these questions are "no", then it
> occurs to me that you _could_ unify the two under a single name, using
> the class boundary as the distinguishing factor (e.g., a method is
> merely a sub declared within a class). If the answer to either is
> "yes", I'd be curious to know how it would work.
I would say "yes".
Having subs inside classes makes creating small utility functions
easier. You could also use private methods for this, but if I dont
need to pass the object instance, why make me? I will say that I think
this distinction will be difficult at first for people steeped in Perl
5 OO.
Having methods outside of classes is less useful, and most of it's
uses are pretty esoteric, however I see no good reason not to allow it
(especially anon methods, as they are critical to being able to do
some of the cooler meta-model stuff).
A method probably cannot be invoked without first being attached to a
class somehow because it needs something to SMD off of. But you could
almost look at a bare (and named) method as a mini-role, so that:
method unattached_method ($::CLASS $self:) { ... }
is essentially equivalent to this:
role unattached_method {
method unattached_method ($::CLASS $self:) { ... }
}
which of course brings up the possibility of this syntax:
$object does unattached_method;
^Object does unattached_method;
as a means of adding methods to a class or object (ruby-style
singleton methods).
Of course, this could also just be my not-quite-caffinated-enough
brain talking too.
Stevan
Jonathan Lang
> Jonathan Lang wrote:
> > Can subs be declared within classes? Can methods be declared without
> > classes?
>
>
> Having subs inside classes makes creating small utility functions
> easier. You could also use private methods for this, but if I dont
> need to pass the object instance, why make me? I will say that I think
> this distinction will be difficult at first for people steeped in Perl
> 5 OO.
Sounds reasonable. I'm curious: can anyone think of any _public_ uses
for subs that are declared within classes?
> Having methods outside of classes is less useful, and most of it's
> uses are pretty esoteric, however I see no good reason not to allow it
> (especially anon methods, as they are critical to being able to do
> some of the cooler meta-model stuff).
OK; so declaring a method outside of a class could let you define one
method that applies to a wide range of classes, without having to
declare a separate method for each class. I can see how that might
come in handy.
> A method probably cannot be invoked without first being attached to a
> class somehow because it needs something to SMD off of.
Why not? IIRC, SMD differs from MMD dispatch-wise in terms of how
many of its parameters are used (one instead of all). If I were to
define "method foo(Complex $bar)" and "multi foo(Num $bar)", I could
then say "foo i" and expect to be dispatched to the method; whereas
"foo e" would dispatch to the sub. Likewise, "i.foo" would dispatch
to the method, while "e.foo" would die due to improper syntax.
At least, that's how I see it. What's the official position on what
happens when you mix SMD, MMD, and/or no dispatch versions of a
routine?
> But you could
> almost look at a bare (and named) method as a mini-role, so that:
>
> method unattached_method ($::CLASS $self:) { ... }
>
> is essentially equivalent to this:
>
> role unattached_method {
> method unattached_method ($::CLASS $self:) { ... }
> }
>
> which of course brings up the possibility of this syntax:
>
> $object does unattached_method;
> ^Object does unattached_method;
(Wouldn't that be "^$object does unattached_method;"?)
> as a means of adding methods to a class or object (ruby-style
> singleton methods).
Hmm: I don't see a need for this with respect to adding methods to a
class; just declare a method that takes a first parameter of the
appropriate class. OTOH, TIMTOWTDI: I could see arguments for
allowing "^$object does method foo() { ... }" as well. OTGH, adding
methods to an individual object would pretty much require the use of
an anonymous role. So the idea that "does" wraps bare methods in an
anonymous role does seem to have merit.
--
Jonathan Lang
Stevan Little
> > Jonathan Lang wrote:
> > > Can subs be declared within classes? Can methods be declared without
> > > classes?
> >
> > I would say "yes".
> >
> > Having subs inside classes makes creating small utility functions
> > easier. You could also use private methods for this, but if I dont
> > need to pass the object instance, why make me? I will say that I think
> > this distinction will be difficult at first for people steeped in Perl
> > 5 OO.
>
> Sounds reasonable. I'm curious: can anyone think of any _public_ uses
> for subs that are declared within classes?
Same uses they would have in Perl 5 I would guess, but I don't usually
do that in Perl 5 so I am hard pressed to come up with a specific
example.
> > Having methods outside of classes is less useful, and most of it's
> > uses are pretty esoteric, however I see no good reason not to allow it
> > (especially anon methods, as they are critical to being able to do
> > some of the cooler meta-model stuff).
>
> OK; so declaring a method outside of a class could let you define one
> method that applies to a wide range of classes, without having to
> declare a separate method for each class. I can see how that might
> come in handy.
>
> > A method probably cannot be invoked without first being attached to a
> > class somehow because it needs something to SMD off of.
>
> Why not? IIRC, SMD differs from MMD dispatch-wise in terms of how
> many of its parameters are used (one instead of all). If I were to
> define "method foo(Complex $bar)" and "multi foo(Num $bar)", I could
> then say "foo i" and expect to be dispatched to the method; whereas
> "foo e" would dispatch to the sub. Likewise, "i.foo" would dispatch
> to the method, while "e.foo" would die due to improper syntax.
I suppose this is all in the details of how we do SMD. It's things
like this that make me think that SMD is just a special case of MMD,
but I think that dead horse has already been beaten here, and I am not
in the mood to reanimate it really.
> At least, that's how I see it. What's the official position on what
> happens when you mix SMD, MMD, and/or no dispatch versions of a
> routine?
>
> > But you could
> > almost look at a bare (and named) method as a mini-role, so that:
> >
> > method unattached_method ($::CLASS $self:) { ... }
> >
> > is essentially equivalent to this:
> >
> > role unattached_method {
> > method unattached_method ($::CLASS $self:) { ... }
> > }
> >
> > which of course brings up the possibility of this syntax:
> >
> > $object does unattached_method;
> > ^Object does unattached_method;
>
> (Wouldn't that be "^$object does unattached_method;"?)
No, I am attaching the method (well role really) to the class ^Object.
There is no such thing as ^$object IIRC.
> > as a means of adding methods to a class or object (ruby-style
> > singleton methods).
>
> Hmm: I don't see a need for this with respect to adding methods to a
> class; just declare a method that takes a first parameter of the
> appropriate class. OTOH, TIMTOWTDI: I could see arguments for
> allowing "^$object does method foo() { ... }" as well. OTGH, adding
> methods to an individual object would pretty much require the use of
> an anonymous role. So the idea that "does" wraps bare methods in an
> anonymous role does seem to have merit.
exactly the conclusions I came too as well, which is one of the reason
why I really like hanging out on this mailing list
:)
- Stevan
Jonathan Lang
> Jonathan Lang wrote:
> > > $object does unattached_method;
> > > ^Object does unattached_method;
> >
> > (Wouldn't that be "^$object does unattached_method;"?)
>
> No, I am attaching the method (well role really) to the class ^Object.
> There is no such thing as ^$object IIRC.
Upon a closer reading of S12, it appears that both are valid:
"prefix:<^>" is syntactic sugar for method meta, and it returns the
object's metaclass; thus, ^$object is equivalent to $object.meta. I'm
still in the process of trying to grasp the concept of prototype
objects; but it appears that ^Object is the same as ^$object.
--
Jonathan Lang