Austin Hastings wrote:


  role Dog {must bark();}
  role Tree {must bark();}

  class crossPerson {
     method bark() {speak_sharply;}
  }

  class Trog does Tree does Dog {
     method bark() {bark_like_a_trog;}
  }

  multi sub purchase(Dog $mansBestFriend) {...}
  multi sub purchase(Tree $shrubbery) {...}
  multi sub purchase($noisemaker must bark()) {...}

  my crossPerson $jack;
  purchase $jack;

  my Trog $spot;
  purchase $spot;

Which, if any, of the subs should be called in each case?  Or should the
compiler complain of duplicate definitions?
$jack is a crossPerson, which absolutely does NOT have the Dog or Trog or
Tree classes in its C<isa> chain. If Dog and Tree are both "inferred" or
"inferrable" classes, then the two multi declarations (Dog and Tree
arguments) are identical.


Thus, there's probably a warning or an error about conflict of inference for
any call that's not passed an explicitly typed object.

I would say that in the above examples, the calls to C<purchase> must throw a run-time exception, since in both calls, all three of the variants are equally "close" to their argument lists in parameter space.


An exhaustive analysis of the variants could of course detect that the three signatures of the variants are all equivalent at compile-time, but I'm not sure Perl 6 will have (or indeed ought to have) such a robust static type inference mechanism on signatures. Mainly because that kind of inference easily becomes combinatoric in complexity as roles/classes become larger and as the number of parameters to each variant increases.

Damian



Reply via email to