Newsgroups: perl.perl6.language
From: fibon...@babylonia.flatirons.org (Luke Palmer)
Date: Mon, 10 Nov 2003 02:47:53 -0700
Local: Mon, Nov 10 2003 4:47 am
Subject: Re: syntax: multi vs. method
Jonathan Lang writes: Well, "multi" is no longer a declarator in its own right, but rather a > 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. modifier. Synopsis & Exegesis 6 show this. So, what was before: multi daft($x, $y) {...} Is now: multi sub daft($x, $y) {...} I think this makes things even clearer, and has a fine-grained but This easily allows for "multisubmethods" and even "multimacros" I also think it's important to say "multi" explicitly every time you > This is one case where the Huffman coding concept doesn't quite pan out: Yeah, but a multimethod is even more just a "multi method". > "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. 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"). > ===== > __________________________________ You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| ||||||||||||||