On Dec 25, 2007 4:37 PM, Allison Randal <[EMAIL PROTECTED]> wrote:
> Klaas-Jan Stol wrote:
> > I guess you're right :-) I was thinking of ambiguity, like
> >
> > sub foo :multi(Integer, Integer)
> > .param pmc i :invocant
> > .param pmc j
> > .param pmc k :invocant
> > end
> >
> > sub foo :multi (Integer, Integer)
> > .param pmc j :invocant
> > .param pmc k :invocant
> > end
> >
> > but I guess parrot will see that the other foo has 2 parameters while
> the
> > first has 3, and make the selection based on that
>
> Like :optional, the :invocant parameters must all be contiguous. So,
> only the second of those is valid, though you can have as many
> non-:invocant parameters as you like after the last :invocant parameter.
> Also, :invocant parameters can't be :optional.
>
> > BTW, :invocant looks a bit like ".invcant", which is also a directive.
> Can
> > that confuse people?
>
> Do you mean ".invocant"? They are related concepts, as .invocant sets
> the single invocant of a method call, while :invocant tells a
> multisub/method to treat a set of parameters as invocants. Any .sub
> marked with :method and :multi always treats the method invocant as if
> it was marked with :invocant, even though it isn't retrieved with .param.
>
> We might want to consider adding a standard prefix to .invocant, as well
> as to .arg, .result, etc, to make it clear that they're a group of
> directives all combined to make a single PCC call.
we just removed the ".pcc_" prefix... (i know, only from some other
directives...) :-P
anyway, the .invocant, .arg , .result and other directives are "grouped"
together already by the .begin_call/.end_call directives. IMHO, we don't
need a prefix to indicate such a grouping.
Your explanation of .invocant (which yes, I meant by writing ".invcant") and
:invocant is very clear, and I think if explained like that in the docs,
won't result in much confusion.
On a side note, (and somewhat related to the remark Bob mentions in his
reply later in this thread (on Dec 25) about the need for :invocant flags
and inferring the types of paramters involved with the dispatch), specifying
both the types in a :multi() clause AND on the parameters is suboptimal;
they need to "match". The .param directives together specify the signature
of the sub; and the :method() clause specifies which actual runtime types
the dispatch will be based on. Code must be written to check for this match,
to give a simple example:
.sub foo :method(Integer)
.param string y :invocant
...
.end
will inevitably result in an error. Of course, you shouldn't write code like
this. Of course, I'm talking syntactic details here, but I think it's worth
thinking about this.
Would it be possible to write a :multi sub like this:
.sub foo
.param string y
.param pmc a :invocant('Integer')
.param pmc b :invocant('String')
...
.end
and maybe it'd be useful to set a flag (without arguments) :multi on the sub
to make it more clear on first sight that the sub is a :multi.
which means the same as:
.sub foo :multi(Integer, String)
.param string y
.param pmc a :invocant
.param pmc b :invocant
...
.end
So, my point is, by specifying both a :multi (,.....) flag AND :invocant
flags, the dispatch info must be specified twice, if you understand what I
mean. I'd prefer to specify :multi dispatch info at a single location only.
kjs
>
> Allison
>
