[ABE.pm] Is this safe coding practice?

Faber Fedor faber at linuxnj.com
Fri Jun 1 15:37:01 PDT 2007


On 6/1/07, Ricardo SIGNES <rjbs-perl-abe at lists.manxome.org> wrote:
>
> * "Faber J. Fedor" <faber at linuxnj.com> [2007-06-01T12:25:22]
> > I don't think this is what Larry, et. al had in mind when they wrote the
> > parameter passing routines in Perl, but this works for me.  I'm just
> > wondering if there are any hidden gotchas:
>
> I think you're wrong. ;)  The things you're talking about have a lot to do
> with
> the kind of list flattening, stack passing parameter style in Perl 5.
>
> I don't know Larry's intent, but I think that you think this is a bad idea
> on
> levels on which it isn't...


Au contrair!  I deduced that it would work from basic principles ("If Perl
flattens it the way I understand it, then this will work...") and thought it
Way Cool when it did. However, since I haven't seen that idiom anywhere, I
assumed there was a Rule Against It.


> I've got a func that returns the min and max values in an array:
>
> Nitpick:  subroutines never return arrays.  They return scalars or
> lists.  A
> list is an immutable sequence of data, an array is a container that holds
> a
> mutable sequence.


Which is why I can't do

(@MinY, @MaxY) = getMinMax(@foo)

because Perl can't tell where to split the arrays I'm returning, right?

get used to thinking about
> it correctly, and someday you will not make a mistake that you might have
> otherwise made.


I don't need that lecture, you whippersnapper! :-) it's one of my guiding
principles and something I impress on my students.

Here's the thing, though.  I would probably pass a reference in,


I prolly would too, but this was a serendiptous discovery during
refactoring.

See, if you say, now, "get_min_max takes a list of data to minmax" then you
> can
> never, ever change the specifics, because you can't add more
> parameters:  any
> parameter you add is by definition part of the list of data.
>
> There are two solutions:  (1) Later, declare that some sort of datum is
> magic in
> the last value (well, if the last value is a hashref, it's actually
> options),
> but this can be a real pain in the butt.


and it's tacky, too!


 (2) Always pass in an arrayref,
> therefore creating a definition for the semantics of only one parameter.
> Later, you can say that the second param modifies the routine's behavior
> in
> some way.



Then I don't grok the technique here.  If I modified my original code to use
an array ref, the code would look like this:

sub getMinMax {
    my ($data) = @_ ;
    my $stat = Statistics::Descriptive::Full->new(); # a great stats
package!
    $stat->add_data(@$data);
    return ($stat->min(), $stat->max());
}

I don't see how to get/use a second parameter in the arrayref.

--

Faber
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/abe-pm/attachments/20070601/94b474da/attachment.html 


More information about the ABE-pm mailing list