Say I have sub boink($a, ?$b, +$c) { ... }
If I call it as boink(@x, d => 7), then does it result in
$a = \@x
$b = (d => 7)
and the call boink(@x, c => 7), in
$a = \@x
$c = 7
? Assuming that's the case, then change the signature to
sub boink($a, Int ?$b, Str +$c) { ... }
So now does boink(@x, d => 7) evaluate (d => 7) in Int context
(whatever that might mean)?
How about boink(@x, $y => foo())? What context is foo() evaluated in?
No. It results in a (hopefully compile-time) error "no such named
parameter 'd'."
> and the call boink(@x, c => 7), in
>
> $a = \@x
> $c = 7
That's correct.
> ? Assuming that's the case, then change the signature to
>
> sub boink($a, Int ?$b, Str +$c) { ... }
>
> So now does boink(@x, d => 7) evaluate (d => 7) in Int context
> (whatever that might mean)?
It doesn't. But if it did, I believe you'd get the value, not the
key, because that's what pairs evaluate to.
> How about boink(@x, $y => foo())? What context is foo() evaluated in?
Hmmmm... Well, it could be cleverly looked up at runtime before it
evaluated foo(). Or it could evaluate it in scalar context, because
it's in a pair. The latter makes me feel a bit safer....
Luke
So I can't pass in pairs unless
1) it's an expected named argument,
2) I've declared a Pair object argument, or
3) I haven't predeclared (which is the most likely circumstance).
Right?
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
or perhaps
4) you enclose the pair in parentheses
Dave.
Or you have a slurpy hash argument (*%foo). The formal hash
%foo collects all the pairs that don't match an explicit
named (+$bar) argument (or possibly even those too, Larry
did you ever decide about that?) This is useful to pass
in args that are to be passed on to calls in the sub.