Larry Wall writes:
> If you write:
>
> multi method add( $self: Foo $foo, Bar $bar );
>
> then there are multiple add methods in the current class. Note the
> invocant is not optional in this case. Also, there's an implied
> second colon after $bar, indicating the end of the arguments to be
- Original Message -
From: "Jonathan Lang" <[EMAIL PROTECTED]>
> So the following three declarations cover very similar (but not quite
> identical) things:
>
> multi sub call ($a: $b) {...}
> submethod invoke ($a: $b) {...}
> method check ($a: $b) {...}
>
> All three of these use mu
I think most everyone is missing the new simplicity of the current
conception of "multi". It's now completely orthogonal to scoping
issues. It merely says, "I'm putting multiple names into a spot
that would ordinarily demand a unique name."
In other words, what a name means in a given scope is a
Jonathan Lang wrote:
multi sub call ($a, $b: $c) {...}
multi submethod invoke ($a, $b: $c) {...}
multi method check ($a, $b: $c) {...}
Why do we suddenly need to append the "multi" keyword to "submethod" and
"method"?
So the compiler knows we really did mean for that (sub)method to be multip
Luke Palmer wrote:
> Jonathan Lang writes:
> > Luke Palmer wrote:
> > > Well, "multi" is no longer a declarator in its own right, but rather
> > > a modifier. Synopsis & Exegesis 6 show this.
> >
> > I don't know about Exegesis 6,
>
> Then you should probably read it. It is the most recent o
Jonathan Lang writes:
> My apologies for the break in the chain of responses; I lost your reply
> before I could reply to it, and had to retrieve it from the list archives.
>
>
> Luke Palmer wrote:
> > Well, "multi" is no longer a declarator in its own right, but rather a
> > modifier. Synopsis
My apologies for the break in the chain of responses; I lost your reply
before I could reply to it, and had to retrieve it from the list archives.
Luke Palmer wrote:
> Well, "multi" is no longer a declarator in its own right, but rather a
> modifier. Synopsis & Exegesis 6 show this.
I don't
Jonathan Lang writes:
> To make "method" work as an alternative for "multi" in every case, the
> only changes that you'd need to make would be to allow more than one
> invocant to be explicitly specified in the "method" syntax, and to allow
> the positional portion of the parameter list to optional
