[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