On 6/1/07, <b class="gmail_sendername">Ricardo SIGNES</b> <<a href="mailto:rjbs-perl-abe@lists.manxome.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rjbs-perl-abe@lists.manxome.org</a>> wrote:
<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* "Faber J. Fedor" <<a href="mailto:faber@linuxnj.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">faber@linuxnj.com</a>> [2007-06-01T12:25:22]<br>> I don't think this is what Larry, et. al had in mind when they wrote the
<br>> parameter passing routines in Perl, but this works for me. I'm just
<br>> wondering if there are any hidden gotchas:<br><br>I think you're wrong. ;) The things you're talking about have a lot to do with<br>the kind of list flattening, stack passing parameter style in Perl 5.<br>
<br>I don't know Larry's intent, but I think that you think this is a bad idea on<br>levels on which it isn't...</blockquote><div><br>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.
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> I've got a func that returns the min and max values in an array:<br>
<br>Nitpick: subroutines never return arrays. They return scalars or lists. A<br>list is an immutable sequence of data, an array is a container that holds a<br>mutable sequence. </blockquote><div><br>Which is why I can't do
<br><br>(@MinY, @MaxY) = getMinMax(@foo)<br><br>because Perl can't tell where to split the arrays I'm returning, right? <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
get used to thinking about<br>it correctly, and someday you will not make a mistake that you might have<br>otherwise made.</blockquote><div><br>I don't need that lecture, you whippersnapper! :-) it's one of my guiding principles and something I impress on my students.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Here's the thing, though. I would probably pass a reference in,</blockquote>
<div><br>I prolly would too, but this was a serendiptous discovery during refactoring.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
See, if you say, now, "get_min_max takes a list of data to minmax" then you can<br>never, ever change the specifics, because you can't add more parameters: any<br>parameter you add is by definition part of the list of data.
<br><br>There are two solutions: (1) Later, declare that some sort of datum is magic in<br>the last value (well, if the last value is a hashref, it's actually options),<br>but this can be a real pain in the butt. </blockquote>
<div><br>and it's tacky, too!<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> (2) Always pass in an arrayref,<br>therefore creating a definition for the semantics of only one parameter.
<br>Later, you can say that the second param modifies the routine's behavior in<br>some way.</blockquote><div><br> </div>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:
<br><br>sub getMinMax {<br> my ($data) = @_ ;<br> my $stat = Statistics::Descriptive::Full->new(); # a great stats package!<br> $stat->add_data(@$data);<br> return ($stat->min(), $stat->max());<br>
</div>}<br><br>I don't see how to get/use a second parameter in the arrayref.<br><br>--<br><br>Faber<br><br>