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).
| [reply] |
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] |
| [reply] |
