diff --git a/src/multi-dispatch.pod b/src/multi-dispatch.pod index 1b406bb..d0ce9c4 100644 --- a/src/multi-dispatch.pod +++ b/src/multi-dispatch.pod @@ -33,8 +33,8 @@ can be found at L. } multi to-json($d where undef) { 'null' } - multi to-json($s) { - die "Can't serialize an object of type " ~ $s.WHAT.perl + multi to-json($d) { + die "Can't serialize an object of type " ~ $d.WHAT.perl } @@ -103,3 +103,31 @@ line with C prints a higher number than the first. (TODO: insert side note "Don't do that at home, kids! Type checks with side effects are a B bad idea in real world code") + +Back to the JSON example, there's one candidate not yet explained. + + multi to-json($d) { + die "Can't serialize an object of type " ~ $d.WHAT.perl + } + +This has not explicit types or constraint on its parameter at all, so it +defaults to C - and thus matches any object we might pass to it. The code +just complains that it doesn't know what to do with the argument, because JSON +is just defined for some basic structures. + +That might look simple at first, but if you look closer you find that it +doesn't just match for objects of all type for which no other candidate is +defined - it matches for I objects. Including C, C, C and +so on. So for a call like C there are two matching candidates - +C and C. + +If you try it out, you'll find that the dispatcher (which is the part of the +compiler that decides which candidate to call) still calls the C +candidate. + +The explanation is that since C is a type that conforms to C, it is +considered a tighter match for an integer. More generally speaking if you have +two types C and C, and C conforms to C (or C is the Perl 6 +programmer says), then an object which conforsm to C does so more +tightly than to C. And in the case of a multi dispatch the tightest match +always wins.