Jonathan Lang writes:
> 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
> 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
