I never use die in CGI. I use a custom die_nice() routine which you will see dozens of references to if you do a Super Search for 'tachyon die_nice'. This is not a CGI, this is a demo snippet to illustrate a point so using die is perfectly appropriate. Your sarcasm is wasted.

Presenting OUT parameters to someone (obviously very inexperienced) with a "this is an OK way to do it" and not mentioning the problem I noted is sub optimal IMHO. You know that they will probably use the code verbatim.....

If you use OUT parameters much you will get caught passing constants to them. These bugs may not immediatly be obvious. You avoid this problem by not using them. I would be interested to see a good example of where they are a powerful and indespensible language feature given that you can easily pass references to and from subs.

If you are doing a code review which is easer to understand without looking at cleaner()

# for sub cleaner { my $var = shift; $var =~ s/foo/bar/; $var }
my $var = cleaner($var);
# then maybe lines later...
print $var
# or in a single line
print cleaner($var);

# or this if you have sub cleaner { $_[0] =~ s/foo/bar/ }
cleaner($var);
# then maybe lines later...
print $var;
# and you can't
print cleaner($var)
# unless you have sub cleaner { $_[0] =~ s/foo/bar; $_[0] }
[download]

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

One good example which comes to my mind is a helper subroutine I wrote for a test suite of one of my modules. Simply put that module has a subrotuine which given a set of input parameters can generate some output. In the test suite the helper subroutine wraps this call and compares the output with some file. If it matches the test is passed and if it doesn't it is not passed. The problem I had is that it in some cases it was ok for the output to vary slightly (for example it could contain current datatime or module version which change with time). So I had to use callback subroutine which cleaned up the output before comparing with the file.

Now compare:

# using OUT parameters
run_test(params => \%params, filename => 't/foo/bar',
         cleanup => sub { $_[0] =~ s/foo/bar/ });

# not using OUT parameters
run_test(params => \%params, filename => 't/foo/bar',
         cleanup => sub { my $var = shift; $var =~ s/foo/bar/; $var })
+;
[download]

To my taste first version is much cleaner.

As for my sarcasm. Probably it was wasted and I'd better to reword it to express myself better. The thing is that for any dynamical language like Perl runtime errors is a norm so I simply cannot accept argument that feature which might cause runtime error is a bad.

--
Ilya Martynov, ilya@iponweb.net
CTO IPonWEB (UK) Ltd
Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
Personal website - http://martynov.org

If you use OUT parameters much you will get caught passing constants to them.

Perhaps, as a general rule. (It is Murphy's Law, after all.) But I highly doubt that someone is going to try to use this cleaner() to clean up a string of literal HTML.

These bugs may not immediately be obvious. You avoid this problem by not using them.

You avoid this problem by paying attention to the caveats on the API. If the doco says "Don't pass a constant", don't pass a constant. If the doco says "This function throws an exception on error", then you wrap the call with eval{}. (Or allow that your program may abort.)

... given that you can easily pass references to and from subs.

And why do references make any difference? (Hint: they don't.)

    cleaner( \"to be cleaned" );

    sub cleaner {
        my $ref = shift;
        $$ref =~ s/foo/bar/;
    }
[download]

results in the same error: Modification of read-only value attempted.

jdporter
...porque es dificil estar guapo y blanco.