My apologies for the break in the chain of responses; I lost your reply before I could reply to it, and had to retrieve it from the list archives.
Luke Palmer wrote: > Well, "multi" is no longer a declarator in its own right, but rather a > modifier. Synopsis & Exegesis 6 show this. I don't know about Exegesis 6, but Synopsis 6 (http://dev.perl.org/perl6/synopsis/S06.html) is still showing multi to be a declarator on par with sub, method, rule, and macro. > I think this makes things even clearer, and has a fine-grained but > elegant control over the "scope" of the routine. Agreed; I'd like something like this to be implemented. > This easily allows for "multisubmethods" and even "multimacros" > (provided you have yourself a polymorphic object at compile time). For the record, subs never have invocants as currently described - so you could easily say that any sub that has an invocant is actually a submethod: sub touch ($a: $b) {...} would be synonymous with: submethod touch ($a: $b) {...} > 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. That's probably good programming advice; but it should remain advice rather than being a requirement. If you allow the distinction between a method and a multimethod to be determined implicitly, you can, if you choose, ignore the "submethod" and "multi" keywords altogether with minimal loss of capabilities: submethod touch ($a) {...} multi watch ($a, $b) {...} would be equivelent to sub touch ($_: $a) {...} method watch ($a, $b:) {...} ===== Jonathan "Dataweaver" Lang __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
