Klaas-Jan Stol wrote:
Earlier I read over this, thinking: there's probably a good reason for that
(the need for being contiguous), but I haven't figured it out yet.
For sake of documentation, could you please explain why this is so?
so, why would it not be possible to write this:
sub foo :multi
.param pmc x :invocant('Integer')
.param pmc y
.param pmc z :invocant('Integer')
..
and
sub foo :multi
.param pmc x :invocant('Integer')
.param pmc y
.param pmc z :invocant('String')
The former "foo" can be thought of as having signature "Integer, *, Integer"
and the second "Integer, *, String", (where * means any type, don't care).
I don't see a particular problem. Not that I need to be able to do this,
just wondering why this rule is so.
From both a parsing and self-documentation perspective, it's clearer to
explicitly say:
.sub foo :multi
.param pmc x :invocant('Integer')
.param pmc y :invocant('ANY')
.param pmc z :invocant('String')
.param pmc a
than it is to simply leave 'y' blank.
The behavior of the parameters 'y' and 'a' are a bit different. The 'a'
parameter is only considered at the very start to knock out signatures
that couldn't possibly fit (wrong number of required parameters). The
'y' parameter is a full participant in multi-dispatch, and contributes
to the overall score of the signature for a particular call. An
"Integer, Integer, Integer" signature may be considered a better match
for a call than "Integer, *, Integer" (when the call is all Integers),
because it's more specific to the particular types passed.
Allison
