in reply to Re: Re: style q: duplication? of variables
in thread style q: duplication? of variables

Come on, cheer up, it's not as bad as it seems :-)

Most functions start with:

sub mysub { my($first_param, $second_param, $and_so_on) = @_; # rest of the function }
and this actually makes copies of received parameters.

There's no need to specially highlight this way of passing parameters (as opposed to other languages) because... it's the only way that Perl supports, as perldoc perlsub will confirm you.

I think that, from a Practical Extraction and Report Language perspective, this made a lot of sense when he invented the language. From a KISS (Keep It Simple, Stupid) point of view, if you decide to implement only one way of passing parameters, it's better to implement the most useful one...

This does not mean that you should expect your variables to change all the time, or to contain unreliable data. If you check perldoc perlfunc, you'll see that only functions that need to change their parameters' values do so. As usual, Perl gives you enough flexibility to exercise common sense without draconian restrictions (or to hang yourself with your own rope). You can find similar ideas (it's up to the programmer to be clear and polite, not up to the language to force you to behave properly) in the Object Oriented design of Perl.

References should be considered as a way to flexibly handle data structures rather that a way to show that you're going to change the value held in the variable. One of the most compelling reason to use references is that, if you pass two lists to a function, they will be collapsed and flattened into @_. I think this is JAUPF (Just Another Useful Perl Feature) when you deal with a variable number of arguments, even though it was kind of annoying under some circumnstances in Perl 4. Well, today, if you want to keep the array separated, just pass a reference to them :-)

-- TMTOWTDI