Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

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

by perl-diddler (Chaplain)
on Mar 30, 2013 at 15:06 UTC ( [id://1026282]=note: print w/replies, xml ) Need Help??


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

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.

Replies are listed 'Best First'.
Re^7: How to return values from a hash?
by Athanasius (Archbishop) on Mar 31, 2013 at 07:16 UTC

    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

    bar(@args);

    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?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1026282]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (7)
As of 2024-03-28 10:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found