develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Things you can't do in a signatured sub

Thread Previous | Thread Next
From:
Darren Duncan
Date:
January 20, 2022 07:26
Subject:
Re: Things you can't do in a signatured sub
Message ID:
76e437c7-9edb-9dbd-f0f5-53a5f92c1a79@darrenduncan.net
On 2022-01-19 11:08 p.m., Yuki Kimoto wrote:
> 2022-1-20 14:32 Dan Book wrote:
>     ($arg, @rest)
> 
> 
> Do you recommend the following code to the Perl users?
> 
>    sub foo ($arg, @rest)  {
>      my ($foo, $bar) = @rest;
>    }
> 
> Instead of
> 
>    sub foo ($arg, $foo, $bar)  {
>    }

For the scenario where we want foo() to effectively have multiple alternative 
parameter lists, and we are unwilling to have a different sub name for each 
distinct parameter list, and Perl doesn't support overloading, then the first 
option is indeed the best option that we have.

The second option is best when foo just has one parameter list to support.

In the general case, where alternatives are supported, the parameters which are 
constant between all variants should be spelled out individually in the 
signature, and @rest would have the parameters that vary.

In the special case of multiple alternative parameter lists where all the 
alternatives have the same arity, we can instead have something like this:

     sub foo ($arg, $foo_or_x, $bar_or_y)) {
     }

... whatever the developer wants to do, they are given the choice.

-- Darren Duncan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About