in reply to Re: Strange modification of @_
in thread Strange modification of @_

Yes, that's it -- don't know why I couldn't see it. However, aarrgghh, I don't see an obvious fix for this that doesn't rely on fn() knowing how it's called or the caller (in the outer substitution) knowing how fn() is going to use its argument list. It seems very unnatural to write s/(x)/fn "$1"/e (with quotes around the argument) and it seems equally unnatural to write the body of fn() any differently (by making a copy of $_[0] before performing the substitution. In general, I certainly don't expect that the argument list to a function will be changed merely by doing something as innocuous as performing substitution on a local string.

I virtually never use fn("$var") instead of fn($var), but I guess if var is a global, including $1, $2, etc, then the safest thing to do is wrap it in quotes to copy the value.

Replies are listed 'Best First'.
Re^3: Strange modification of @_
by ikegami (Patriarch) on Apr 23, 2009 at 22:05 UTC

    it seems equally unnatural to write the body of fn() any differently (by making a copy of $_[0] before performing the substitution.

    What are you talking about? Using one of my ($str) = @_; or my $str = shift; is standard practice, hardly unnatural.

    If the issue is that you want both the original and the transformed string, you might also be interested in the following idiom: 

    sub fn {
   my ($old) = @_;
   (my $new = $old) =~ s/.../.../;
   ...
}

    [download]
[reply]
[d/l]
[select]
      I meant that both of the potential fixes for this feel unnatural:
      1. using s/(x)/fn "$1"/e (with quotes around $1), or
      2. using what you suggested: (my $new = $old)... or any other form of that.
      Both fixes require an extraordinary amount of coupling between the caller and the function. Either:
      1. the caller needs to know that the argument to fn() will be used directly from @_ after a regexp, or
      2. the function needs to know that the argument is an alias of a global variable which will be modified by the regexp.
      Only if they have this tight coupling does it make sense to use either of these two precautions to avoid the issue I ran into.

      I think the takeaway for me is that when passing $1, etc into a function, that it should be quoted (to copy it), even though the general rule is when passing a variable $var into a function, (almost) never should it be quoted, as in fn("$var"). This feels exactly like the kind of kludgy rules you have to remember to use C++ "correctly".

[reply]
[d/l]
[select]
        1. the caller needs to know that the argument to fn() will be used directly from @_ after a regexp, or
        2. the function needs to know that the argument is an alias of a global variable which will be modified by the regexp.

        Not true. Just use the standard calling convention. 

        sub f {
   my (...) = @_;
   ...
}

        [download]

        I think the takeaway for me is that when passing $1, etc into a function, that it should be quoted (to copy it)

        Maybe. I would have thought it was: There are risks in avoiding the standard calling convention.

        You're doing something unnatural then claim you have to take unnatural measures to avoid the resulting problems.

        You increase cohesion by using aliases then complain of the increased cohesion.

        What would like from us?

[reply]
[d/l]

In Section Seekers of Perl Wisdom