It has been mentioned in Apocalypse 6 that there may not be a difference 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
