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 Exegesis
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 of the
documents,
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 multiply
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
- 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 multiple
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
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 know
It has been mentioned in Apocalypse 6 that there may not be a difference
between a method and a multimethod that has one invocant. If this does
indeed turn out to be the case, I'd like to see the method syntax being
expanded to act as an alternative to the multi syntax:
method- In the method
