On Tue, Mar 18, 2003 at 02:46:17PM -0600, Ralph Mellor wrote: : If one deploys a sub with optional-positional parameters, : one can't add a required parameter later without breaking : any existing calls that make use of any o-p parameters. : Right?
Correct. : A6: "An rw parameter may only default to a valid lvalue. If : you find yourself wanting it to default to an ordinary value : because it's undefined, perhaps you really want //= instead:" : : Wouldn't it make sense to allow //= in the sig and have it dwim? Except that if you're planning to write the variable as an "out" parameter, you still have to have it bound to something, whether or not you later choose to default its value using //=. And I think putting both = and //= into the sig is confusing. Since //= has to be a run-time decision anyway, and has no influence on what gets bound to the parameter, it might as well go in the body. : A6: "All unbound named arguments are bound to elements of : the slurpy hash, if one was declared. If no slurpy hash is : declared, an exception is thrown (although some standard : methods, like BUILD, will provide an implicitly declared : slurpy hash--known as %_ by analogy to @_--to handle surplus : named arguments)." : : What about there always being an implied %_ and @_, but if : either get entries, perl generates a warning (unless it's : one of the methods like BUILD)? Then someone will turn off warnings to get the implicit %_ and @_ everywhere, and every subroutine will have to include the code to check for named parameters, which means every sub runs slower. The lack of implied %_ or @_ is meant to make it possible to compile faster sub calls when you know a sub can't have named parameters, or at least when you can know all the possible names of parameters at compile time, and can rearrange them into positional form internally from the caller end at compile time, so that the callee doesn't have to process them in random order at run time, which is slow. Even things like multimethods can have optimizations of this form. If all currently declared multimethods of a particular name have the same parameter names with different types, then on the assumption that more multimethods will not be declared under that name, you can optimize named notation into positional. Perhaps there will need to be a way to commit to a particular set of multimethods if you want to enable this optimization at CHECK time. Or maybe a way to declare that "all multimethods of this name must start with these n positional parameters with the following names..." (For the first version, we probably just restrict multimethod invocants to positional paramaters anyway. But the question is whether we can relax that at some point. Restricting multimethod invocants to positional parameter has the interesting side effect of prohibiting the currying of multimethod invocants, unfortunately.) : A6: "It's also possible to transition directly from positional : arguments to the variadic list if optional positional : arguments have been completely specified." : : Or if one uses pipes, right? Yes, that's an explicit variadic transition. Larry
