On Oct-05, Luke Palmer wrote:
> Steve Fink writes:
> > Ok, I'm back to argument passing. I'm starting a new thread because
> > I'm lazy and I have to scroll back too far in my mailer to see the old
> > arg passing thread. :-) And yes, most of this message should also be
> > on -languages.
>
> Which it now is. Although, there are some internals issues, too, so I
> wonder how we can do this. How about, when someone responds to either
> an -internals- or a -language-specific question, he directs it only to
> the appropriate list.
And I guess cross-post one last time when moving a piece from one list
to another?
> > I can use names to pass required arguments, but all positional args
> > must precede all named args. So then is this legal:
> >
> > f(1, 2, b => 1.5)
> >
> > or must all of the positional args referred to by named parameters
> > follow those passed positionally? (There are two orders -- argument
> > order and parameter order. In which of those two must all positionals
> > precede the named params?)
>
> Both. (In parameter order, named-only must come after positionals) So
> f(1, 2, b => 1.5) was correct.
Huh? In argument order, clearly all the positionals precede the named.
But if 2 is bound to $c, then they are out of parameter order. Or does
that not bind 2 to $c? Are both 2 and 1.5 bound to $b (and resolved as
below)?
> > In
> >
> > sub j($a, ?$b, *%c) { ... }
> >
> > can I actually pass %c after the rest of the params? If I call it with
> >
> > j(1, $blue => 'red')
> >
> > then does that compile down to
> >
> > .param 1
> > .param named_arg_table
> >
> > ? How is the callee supposed to know whether the 2nd param is $b or
> > %c? What if $blue happened to be "b"?
>
> If $blue was 'b', then j would get $b to be 'red'. Run-time positionals
> are another one of those things I don't expect to see all that often
> (but that might be a different story in my code >:-).
Sorry, that was an implementation question, not a language question.
>From the language-level, clearly the effect you want is for 1 to be
bound to $a and 'red' to be bound to either $b or %c{$blue}, depending
on whether $blue eq "b". The question is in what order the parameters
should be passed. Both work, but both cause problems.
> The real problem arises in:
>
> j(1, 2, $blue => 'red')
>
> If $blue happens to be 'b'. I think the behavior then would be $b gets
> 2, and %h gets { b => 'red' }. In particular, I think it's wrong to
> croak with an error here.
Larry had some discussion of this:
However, it is erroneous to simultaneously bind a parameter both by
position and by name. Perl may (but is not required to) give you a
warning or error about this. If the problem is ignored, the
positional parameter takes precedence, since the name collision might
have come in by accident as a result of passing extra arguments
intended for a different routine. Problems like this can arise when
passing optional arguments to all the base classes of the current
class, for instance. It's not yet clear how fail-soft we should be
here.
Oh, and in discussing this, I'm wondering about one bit of vocabulary:
do you bind an argument to a parameter, a parameter to an argument, or
do you bind an argument and parameter together? E6 binds arguments to
parameters. What if you are binding multiple arguments to a single
parameter, as is the case with slurpy params?
It doesn't matter, really, but in my documentation and discussion I'd
like to be consistent, just because this stuff is already a ways
beyond my mental capacity and anything that simplifies things is
greatly appreciated!
