Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

Dov Wasserman wrote: My concern is that given an argument supplied as a pair (foo => "bar"), it is not clear which type of parameter is meant to be supplied. If there is no such named parameter, we know that the argument was intended for the slurpy hash. However, what if the method designer later a

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

"Aldo Calpini" <[EMAIL PROTECTED] > wrote in message ... > > if you decide to reimplement logError to be just: > sub logError {# implicit ([EMAIL PROTECTED]) > # ... > } > using a Pair, you still have someting (a Pair object) that you ca

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

On Wed, 2004-05-05 at 22:36, Dov Wasserman wrote: > sub logError($msg, Int +$prio = 4, *%errorInfo) { [...] > logError("Database error", module => "DB.pm", line => 263, prio => "HIGH"); > > After the New And Improved logError() routine is rolled out, it seems to me > that this log statement shoul

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote: > To distinguish these two cases, what if we used the := binding operator to > bind an argument to a named parameter: > > logError($err_msg, prio := 3); but how would this look like to a subroutine that is not defined to accept a named parameter c

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

"Aldo Calpini" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote: > > > > After the New And Improved logError() routine is rolled out, it seems to me > > that this log statement should generate a compile-time error, since the > > named In

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote: > After the New And Improved logError() routine is rolled out, it seems to me > that this log statement should generate a compile-time error, since the > named Int parameter "prio" is given a non-integer argument "HIGH". At best, > this should be a

Named parameters vs. slurpy hash syntax: brittle call syntax!

[Reposting this from earlier this week, since it didn't seem to make it to the news server. -dmw] A question about the calling syntax of named parameters versus arguments supplied to a slurpy hash. If I understand A6 and A12 correctly, all Pair arguments to a function (sub, method, etc.) are scann