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:37
Subject:
Re: Things you can't do in a signatured sub
Message ID:
e02974d3-5ad4-cad2-630f-e1485502d74c@darrenduncan.net
On 2022-01-19 11:14 p.m., Yuki Kimoto wrote:
> 2022-1-20 14:20 Darren Duncan wrote:
>     So here's a question.  The way signatures work now, if one puts "@" at the end
>     of the signature,
> 
> Would you recommend the following code to Perl users if they want the old codes 
> to be a signature without changing its behavior?
>    # Old code
>    sub f1 {
>      my ($a1, $a2) = @_;
>    }
> 
>    # ...
> 
>    sub f1000 ($a1, $a2) {
>      my ($a1, $a2) = @_;
>    }
> 
>    # New codes
>    use feature 'signatures';
> 
>    sub f1 ($a1, $a2, @) {
>    }
> 
>    # ...
> 
>    sub f1000 ($a1, $a2, @) {
>    }

Yes I would.  That is the textbook example for the most common cases of a 
subroutine where we want to use signatures while preserving the old behavior 
including the lack of arity check.

Well except for the common idiom of a combined getter/setter, which I personally 
don't like but it is common.  So in that case you would have in the new version 
of that like this:

     sub myaccessor ($name, @maybe_new_value) {
         if (scalar @maybe_new_value > 0)
             $props->{$name} = $maybe_new_value[0];
         }
         return $props->{$name};
     }

-- 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