Author: lwall
Date: 2010-05-05 20:10:44 +0200 (Wed, 05 May 2010)
New Revision: 30556
Modified:
docs/Perl6/Spec/S06-routines.pod
Log:
[S06] More rationale for the proto simplification
Modified: docs/Perl6/Spec/S06-routines.pod
===================================================================
--- docs/Perl6/Spec/S06-routines.pod 2010-05-05 17:52:04 UTC (rev 30555)
+++ docs/Perl6/Spec/S06-routines.pod 2010-05-05 18:10:44 UTC (rev 30556)
@@ -139,6 +139,24 @@
do-something-after();
}
+Note that, in addition to making multis work similarly to each other,
+the new proto semantics greatly simplify top-level dispatchers, which
+never have to worry about multis, because multis are always in the
+second half of the double dispatch (again, just in the abstract, since
+the first dispatch can often be optimized away, as if the proto were
+inlined). So in the abstract, C<foo()> only ever calls a single
+only/proto routine, and We Know Which One It Is at compile time.
+
+This is less of a shift for method dispatch, which already assumed that there
+is something like a single proto in each class that redispatches inside
+the class. Here the change is that multi-method dispatcher needs to look
+more widely for its candidates than the current class. But note that our
+semantics were inconsistent before, insofar as regex methods already had to
+look for this larger managed set in order to do transitive LTM correctly.
+Now the semantics of normal method protos and regex protos are nearly
+identical, apart from the fact that regex candidate lists naturally have
+fancier tiebreaking rules involving longest token matching.
+
=head2 Named subroutines
The general syntax for named subroutines is any of:
