Michael Lazzaro wrote:

Suppose I wanted to do something like:

   sub draw_triangle( Point $a, Point $b, Point $c );
-and-
   sub draw_triangle( int $x1,$y1, int $x2,$y2, int $x3,$y3 );
Err. Why would you only want the X parameters to be explicitly typed?
I suspect you mean:

     sub draw_triangle(int $x1, int $y1, int $x2, int $y2, int $x3, int $y3);


-and-
   (every conceivable combination of those damn arguments)


Would the currently-pondered multimethod syntax support anything roughly
analogous to the pseudocode:

   sub draw_triangle(
      ( Point $a | int $x1,$y1 -> Point.new($x1,$y1) ),
      ( Point $b | int $x2,$y2 -> Point.new($x2,$y2) ),
      ( Point $c | int $x3,$y3 -> Point.new($x3,$y3) )
   ) {
      ... stuff using $a, $b, $c ...
   }

such that I don't need 2^3 separate damn prototypes of C<draw_triangle>?
Probably not. To solve this particular problem, I'd specify that pairs
of X/Y coordinates need to be passed as...well...pairs:

    sub  draw_triangle ( Point|Pair $a is copy,
                         Point|Pair $b is copy,
                         Point|Pair $c is copy) {
        when Pair {$_ = Point.new(.key,.value)} for $a, $b, $c;
        ...
    }


    draw_triangle($p1, 3=>4, $p2)


Sorry for this question, but this is one of the Big Ones that's been
bugging me for quite some time.  Frequently (usually?), multimethods are
built such that there is one "true" case, and all other variations are
utterly minor derivations of that case...
That's so. But your proposed solution relies on us being able to define tuple types, and I'm not sure we're planning a type system strong enough for that.

If we *were* (and I'm not saying we're even considering it!), I imagine your
example would become something like:

class XY is Tuple(int, int);

sub draw_triangle ( Point|XY $a is copy,
Point|XY $b is copy,
Point|XY $c is copy) {
when Pair {$_ = Point.new(@$_)} for $a, $b, $c;
...
}

draw_triangle($p1, (3,4), $p2)


Damian

Reply via email to