in reply to Re^6: How to return values from a hash?
in thread How to return values from a hash?

Hello perl-diddler,

By looking at that most perl programmers would know that it takes 3 mandatory vars, and an optional 4th;

You could also use a runtime check. Compare the subroutines foo and bar:

#! perl
use strict;
use warnings;

sub foo
{
    my @x = @_;
    die "Incorrect number of arguments$!" if @x < 3 || @x > 4;
    print "$_\n" for @x;
    print "\n";
}

sub bar ($$$;$)
{
    my @y = @_;
    print "$_\n" for @y;
    print "\n";
}

[download]

Both approaches are self-documenting. The advantage of using prototypes is that violations are detected at compile time, which is more efficient. The disadvantage is that the calling syntax is much more restrictive. For example:

my  @args = (2, 3, 5, 7);
foo(@args);

[download]

works as expected, but

bar(@args);

[download]

results in a compilation error because the first $ prototype puts @args into scalar context, resulting in a single value of 4 (the number of elements in the array). To call bar successfully in this situation you would need something ugly like this:

bar($args[0], $args[1], $args[2], $args[3]);

[download]

Of course, prototypes can be useful; but when you write:

I always use prototypes -- even on methods where they don't matter -- for no other reason than, minimally, documentation. It's a self-imposed discipline.

this sounds (to me) like an attempt to convert Perl into a statically typed language. Much better to embrace Perl’s dynamic nature, use natural Perl idioms by default, and save prototypes for those (rare) situations in which they’re really useful.

See Far More than Everything You've Ever Wanted to Know about Prototypes in Perl -- by Tom Christiansen.

Athanasius <°(((>< contra mundum Iustus alius egestas vitae, eros Piratica,

Replies are listed 'Best First'.
Re^8: How to return values from a hash?
by perl-diddler (Chaplain) on Apr 21, 2013 at 10:26 UTC
    I've read that article -- a long time ago and just re skimmed it. It doesn't really say much that's is surprising to someone who uses prototypes all the time -- even on methods where their typing is pointless (documentation benefit for me, but pointless as far as catching errors).

    **If** I have routines that are not called and/or they are in areas fraught with danger, I do many checks. Example: this is a snippet of code I wrote for a util for _myself_.

    The structure of the sub, is such that it's body doesn't begin until 118 lines below the 'sub'. In the intervening lines are nested subroutines to simplify the code below. Just above where the main code starts (the main code being 25 lines long!), there are two routines (36 lines) of code that JUST does error checking. 

        ## "Devel" - extra checking code
    local 
    *validate_returned_pointer = sub ($$) {
      my ($rp,$mpn)=@_;
      my $refp= ref $rp;
      $refp || die P "$self: undef inode returned in arg# %d", $mpn;
      $rp->can('Ino') || die P "$self: Bad type: %s: Cannot get ".
                                "Ino num in arg# %d", $refp, $mpn;
      $rp->Deleted_Ino_chk &&
        die P "$self: Deleted Ino returned in arg# %d", $mpn; 
      };

    use constant first_call       =>  1;
    use constant subsequent_call  =>  2;

    local * param_checks = sub ($) {
      if (scalar @$retp) {
        die "Error -- passed back params when Size index and\n".
            "next_in_Q are in pre-run state (%s, %s)", $mp->{Size2ss_n
+odes},
            $mp->{nextbase} unless $mp->{Size2ss_nodes} || $mp->{nextb
+ase};
            TPe "$self: received %s params", scalar @$retp;

        die P "$self: Too many arguments (%s)", scalar @$retp if @$ret
+p > 2;
                                              # validate returned poin
+ters
        for (my $mpn = 0; $mpn <= $#$retp; ++$mpn) {
          validate_returned_pointer($retp->[$mpn], $mpn); }
        return subsequent_call;
      } else {
        die "$self: takes 1 or 2 params: a surviving inode\n".
            "if a link occurred, or both there was no linking.",
            if $mp->{size_idx} != 0;
        return first_call;
      }
    };

    state $exec;    #performs same 'function' as first/subseq call w/o
+ checks 

    if (($mp->{optimize} and $exec||=$exec++) || 
                                          param_checks() == subsequent
+_call) {

    [download]
    Note the 'optimize' param -- I fully expect those routines not to be executed in the final solution (though they make <1% of a difference in overall execution speed).

    Also that entry point is the only place those routines are used.. and they just do parameter checking (even my throw away error routines have prototypes!)

    ....Vs.....the code above... is the largest single execution/cpu sucker of any part of a program. Adding anything that would slow down runtime -- would directly harm performance -- since the code is critical path code that is frequently called.

    I don't often find a need for dynamic types. Your example would be rare in my code, since 3 params is about the cutoff point for passing stuff in a reference or hash in my usage (as a general rule). So my prototype would look like 

    sub bar($) {...}
 # and the calling routines would use either...
[1,2,3,4]
 # or
{p1=>1, p2=>2...}

    [download]
    Cuz I have a pretty short, short term memory -- unless I sprinkle my code with lots of hints (including prototypes), I'll find it near impossible to figure out what my "previous self" wrote or was doing.

    I've sat down and looked at code written 18-24 months prior and didn't even recognize it for my coding style, let alone as code that I wrote!

    So when I put in lots of error checking, it's not to protect others so much, but to protect myself from myself! Almost any error that can possibly happen I will eventually have happen in my code. So better to write the code defensively up front and save myself headaches later.

    Make sense? ;-)

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom