On Fri, Jul 08, 2005 at 11:13:27AM -0400, Chip Salzenberg wrote: : Tt makes sense to scan the pairs containing named arguments by : iterating through the list of pairs (if any), not by iterating through : the parameters and doing a sequential scan for an appropriately named : pair for each one.
Actually, there are use cases for both approaches. Consider the case where your named parameters are actually a hash of many defaults, only a few of which you might pick out for this call. That is essentially how we've defined the %_ hash to work for Perl 6. It is not an error to have extra unbound named parameters on a method call, because we're passing in the inital values for all the various attributes set by the entire class hierarchy, and each class only picks out the values it's interested in. In such a case it makes sense the main loop to iterate over the positionals and do lookups on any missing ones in the named zone. Even in the absence of a hash representation, the brute force approach will often beat the finessed approach for a small number of arguments, especially if people *usually* fill positional parameters with positional arguments, in which case you get to the end of the positional arguments without making any passes on the named zone. I'm not saying that Perl 6 requires you to do it this way, only that we've intentionally defined the semantics to make the position-major approach feasible. As far as I can see, the only way in which this makes the named-major approach more difficult is that we specify "first wins" rather than "last wins" if there are collisions in the named list so that you don't always have to scan the whole list if you take a position-major approach, and so that you can know that you can pass a specific named argument to override the default in the hash as long as you pass it first. So a named-major approach would need to be a bit careful not to turn into "last wins" semantics. I suppose a hybrid approach is possible, where you do position-major till you find a "hole", then named-major till you run into a hash in the named zone, then finish out doing position-major with lookups on the rest of the name list, on the assumption that the hash is probably the last named colletion, or at least all the hashes will tend to clump at the end of the named zone. : Therefore, it's possible that there will : eventually no longer be a single loop through the parameters. The : concept of strict temporal ordering might thus be lost, Why would strict temporal order be needed for mere binding? : and the idea of "optional parameter up to this point" might also be lost. I don't grok that part. : So apparently I'm going to have to figure out exactly how we support : named parameters or this won't get settled. Fine.... Mmm, have the appropriate amount of fun... :-) Larry
