Jonathan Lang writes: > 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,
Then you should probably read it. It is the most recent of the documents, so what it says is closest to the current thinking. Plus, it's a fun read. > 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. Now that I look, yes, that's true. It's wrong. > > 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) {...} Hmm. Well, that depends on whether calling works like it does in Perl 5. That is, given: multi sub touch (Foo $a: $b) {...} Is this legal: my $x = new Foo; $x.touch; I haven't been able to deduce this. > > 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. Spoken like a true Perl programmer :-) I don't see the win in losing the C<multi> keyword though. Sure, there are 5 fewer characters, but declarations aren't a place where concise and terse are synonymous. IMO, a colon is too small a character for such a large distinction. Misunderstanding the rule slightly can lead to overriding instead of overloading... reminds me of C++ [1]. > 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:) {...} Luke [1] While I haven't the hatred for C++ that quite a few people on this list do, I definitely consider it an "advanced" language, by which I mean there are subtle variants in the rules that cause wildy different behaviors. Beginners (and intermediates) still struggle with this one: class Base { public: virtual int num() const { return 10; } } class Derived : public Base { public: int num() { return 20; } } int main() { Base* b = new Base; Base* d = new Derived; cout << b->num() << endl; // 10 cout << d->num() << endl; // 10 !! } Now why the heck did the call to d->num() return 10??!!! Because they missed a C<const> in the overriding of num(), hiding it instead. This is precisely what would happen if you missed a colon in adding a multimethod. Sorry, I don't want to inflict this kind of pain on Perl programmers.
