Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

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

by CountZero (Bishop)
on Mar 30, 2013 at 10:02 UTC ( #1026263=note: print w/replies, xml ) Need Help??

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

I have some doubts about the following code:
sub _Var ($$$;$) { # Wrkhorse code for manufctrd Vars #note $p->obj, $vn=varname, $wa=wantarray val my ($__, $p, $vn, $wa)=@$_;
  1. Why are you using prototypes in the subroutine definition? Unless you have a very very good reason to use prototypes, you should not use prototypes. And using prototypes to check the type and number of arguments is not a good reason.
  2. What do you think @$_ does? You are dereferencing the global default variable $_ into an array. Didn't you rather want to use the @_ variable which contains the parameters of the subroutine call?
  3. Are you using strict and warnings?


A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

My blog: Imperial Deltronics

Replies are listed 'Best First'.
Re^6: How to return values from a hash?
by perl-diddler (Hermit) on Mar 30, 2013 at 15:06 UTC
    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.

    By looking at that most perl programmers would know that it takes 3 mandatory vars, and an optional 4th; I don't ascribe to the 'no prototypes propaganda', but then I also know their limitations.

    2. answered above where someone asked how _var got called. I needed a way to pass params, from the 'goto' to this... $_ is the only way I know.

    3. always. (else prototypes are even more worthless).

    the Data::Var module defines fields with optional default definitions -- so if you access them through the access routines (which I don't on more speed sensitive areas), you will get a compile time error for trying to access a field that doesn't exist.

      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"; }

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

      works as expected, but


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

      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,

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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1026263]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (3)
As of 2017-03-30 04:09 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (353 votes). Check out past polls.