Re^8: How to return values from a hash?

[perl-diddler]

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

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

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? ;-)