in reply to Re^2: Pass array, then clear
in thread Pass array, then clear

Allowing a subroutine to modify its argument is probably necessary in some cases to keep or enhance the expressive power of the language. And, sometimes, it is necessary to use that feature, just as it is sometimes (but rarely) necessary to use some magical constructs of the language. In most modern languages, however, the default is not to allow that (for example by using a call by value evaluation strategy); and you usually need a special syntax to modify the function arguments (such as, depending on the language, using pointers or references, or by specifying explicitly that the subroutine argument should be "read and write", rather than the default read only).

The fact that you can modify a function argument within the function (provided you really know what you're doing) does not mean, however, that you should do it or that it is a good practice to do so commonly. I do not know whether this is by itself a sufficient reason not to modify the subroutine arguments, but I agree with BillKSmith that most people (including myself) think is is usually a bad idea to do so. Or that, at least, it tends to be confusing and should be avoided when possible.

Having said that, I am certainly not dogmatic on that question, and I prefer to be pragmatic. I certainly usually tend not to modify my subroutines arguments, even though I sometimes find it useful or even necessary to do so (which can be the case for totally different reasons, such as performance or memory footprint, for example).

Replies are listed 'Best First'.
Re^4: Pass array, then clear
by jahero (Pilgrim) on Jan 17, 2018 at 06:33 UTC

    Thanks for putting BillKSmith's sentiment to more verbose form. For some reason, it seems more palatable when presented like this. In retrospect, I guess this particular feature of the language can indeed be confusing. I guess it not like this for me because in my mind changing value of parameters from within the sub is connected with transferring variables I want changed by reference. Thus, in my mind, the problem is non-existent (which in fact is incorrect position)...

    I guess that some code can indeed be seen as kind of a dark magic to person who does not have perfect understanding of the language (which I don't posess). This node would probably be a perfect example of good written, concise, yet hard to read code: trim() magic, if it is not properly commented.

    It is good to talk to smart people. Thanks for the enlightenment.

    edit: but then, I guess that almost any language contains features that are confusing to outsider, so it does not speak of Perl quality. Take JavaScript as an example. It is perceived as modern and quality programming language... and then... https://feross.org/never-use-semicolons/ Now let us talk about confusion. My head is spinning.

[reply]
      Take JavaScript as an example. It is perceived as modern and quality programming language

      "modern" is contestable, given that there are people with university degrees today who are younger than JavaScript but it is all a matter of scale I suppose. "quality" on the other hand is just laughable. Picture the scene:

      CIO: Project Omega is by far the most mission-critical system we will ever construct. Many lives would be lost if the program were to fail at any point. It must be the ultimate in robust coding.
      Head of Software Eng: I guess we'd better use JavaScript then.

      I don't think so.

[reply]

        Well, I am probably the least qualified to comment on this, as my experience with JavaScript is virtually none.

        Reason why I mentioned JavaScript is as follows: One can not deny that JavaScript has considerable traction. This month it is rank 6 on TIOBE index. So "outsider" could easily conclude, that "JavaScript is a great language to learn".

        However, even language which is favoured by the crowd and which is used on servers (NodeJS) can contain horrible "kinks", like the one, which I mentioned.

        So it would seem we are in accord.

[reply]

In Section Seekers of Perl Wisdom