syntax: multi vs. method
Jonathan Lang
between a method and a multimethod that has one invocant. If this does
indeed turn out to be the case, I'd like to see the "method" syntax being
expanded to act as an alternative to the "multi" syntax:
method- In the "method" syntax, you can currently specify zero or one
explicit invocants.
multi- In the "multi" syntax, you can currently specify zero or more
explicit invocants, and you must specify at least one parameter
regardless.
(note: by "explicit invocants", I'm referring to an invocant or a
comma-seperated list of invocants followed by a colon.)
method- If you don't specify any explicit invocants, $_ is used for that
purpose.
multi- If you don't specify any explicit invocants, every parameter is
treated as an invocant.
To make "method" work as an alternative for "multi" in every case, the
only changes that you'd need to make would be to allow more than one
invocant to be explicitly specified in the "method" syntax, and to allow
the positional portion of the parameter list to optionally be terminated
by a colon, regardless of whether you have any named or list parameters.
The only case in which such syntax would be at all awkward would be when
you _don't_ have any named or list parameters, and _every_ positional
parameter is supposed to be an invocant.
This is one case where the Huffman coding concept doesn't quite pan out:
"multi" _is_ one character shorter than "method", but the latter is (to me
at least) much more clear as to its intent and more natural to use. As a
programmer, I don't really care too much about the underlying differences
between how single-invocant methods and multi-invocant multimethods are
dispatched, and I'd rather not have the difference be forced upon me if
there isn't a significant need to do so. To me, a "multimethod" is a
method - one which just happens to have more than one invocant, but a
method nonetheless.
A side benefit of such an expansion of the capabilities of the "method"
syntax would be that similar approaches could be used for "sub" and
"submethod" - expand "submethod" to allow for multiple explicit invocants,
and you can have subs that masquerade as multimethods; allow "sub" to
specify invocants, and the need for the "submethod" syntax all but goes
away (in fact, the only reason to keep it would be for those cases where
you want to use $_ as the invocant - admittedly important cases, to be
sure, so I wouldn't advocate ditching "submethod").
=====
Jonathan "Dataweaver" Lang
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
Luke Palmer
> To make "method" work as an alternative for "multi" in every case, the
> only changes that you'd need to make would be to allow more than one
> invocant to be explicitly specified in the "method" syntax, and to allow
> the positional portion of the parameter list to optionally be terminated
> by a colon, regardless of whether you have any named or list parameters.
> The only case in which such syntax would be at all awkward would be when
> you _don't_ have any named or list parameters, and _every_ positional
> parameter is supposed to be an invocant.
Well, "multi" is no longer a declarator in its own right, but rather a
modifier. Synopsis & Exegesis 6 show this. So, what was before:
multi daft($x, $y) {...}
class Foo {
multi swip($self, $y: $z) {...}
}
Is now:
multi sub daft($x, $y) {...}
class Foo {
multi method swip($self, $y: $z) {...}
}
I think this makes things even clearer, and has a fine-grained but
elegant control over the "scope" of the routine.
This easily allows for "multisubmethods" and even "multimacros"
(provided you have yourself a polymorphic object at compile time).
I also think it's important to say "multi" explicitly every time you
mean it. It allows the compiler to warn you when you're just being
stupid about scoping as opposed to actually wanting to overload the
routine. From a design perspective, it makes it clear that this method
introduces logical control-flow in addition to performing a task.
> This is one case where the Huffman coding concept doesn't quite pan out:
> "multi" _is_ one character shorter than "method", but the latter is (to me
> at least) much more clear as to its intent and more natural to use. As a
> programmer, I don't really care too much about the underlying differences
> between how single-invocant methods and multi-invocant multimethods are
> dispatched, and I'd rather not have the difference be forced upon me if
> there isn't a significant need to do so. To me, a "multimethod" is a
> method - one which just happens to have more than one invocant, but a
> method nonetheless.
Yeah, but a multimethod is even more just a "multi method".
Luke