[ABE.pm] Is this safe coding practice?

[Ricardo SIGNES]

* "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...

> 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.  This doesn't usually matter, but get used to thinking about
it correctly, and someday you will not make a mistake that you might have
otherwise made.

>     ($MinY, $MaxY) = getMinMax(@foo);
>     ($MinY, $MaxY) = getMinMax(@foo, @bar);
>     ($MinY, $MaxY) = getMinMax(@foo, @bar, $fubar);
> 
> assuming you want the min and max values of all the data in @foo, @bar
> and $fubar?

These seem absolutely dandy.

Here's the thing, though.  I would probably pass a reference in, for two
reasons:  First, if you're most often passing in one array, you save memory by
not copying it here.  (If you are passing many, you will have to construct a
new array to reference, so that savings is gone.)  Secondly, it leaves you open
to future expansion of your semantics.

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

-- 
rjbs