On Tuesday, December 10, 2002, at 02:50 PM, Damian Conway wrote:
Simon Cozens asked:*Why* do methods need their parens?
<examples snipped>
*All* of them might be valid interpretations, and *none* of them might be known to be valid (or even knowable) at the point where the code is parsed. Throw multimethods into the mix and things get an order of magnitude worse.All subroutines with multiple signatures would have this problem, right, even normal non-method subs?
Incidentally, the indirect object syntax will suffer from exactly the same problems in Perl 6.
foo $a, $b, $c, $d; # how many args?
So could a general rule be that multimethods (subs or methods with more than one possible variant) require the parens, but subs with one known signature do not?
To solution in both cases is to defer the parameter/argument type checking and the method dispatch until run-time. That works fine, but only if the compiler can determine exactly how many arguments to pass to the method call. For that, it needs either explicit parens, or a default rule.Oof. I had been (foolishly?) hoping that if argument types were known at parse time (due to previous declarations), it would frequently be possible to resolve the multimethod variant during compilation. Now I'm wondering -- because of Perl's ability to add classes/methods at runtime, for example -- if there are _any_ circumstances in which that would be true.
How much overhead do we expect (runtime) multimethods to have? I would guess it to be nontrivial, e.g. substantially worse than normal methods...
MikeL
