%x = ( A => f(1), B => f(2), C => f(3) );
[download]

I suggest your code be hacked so that you're doing:

%x = ( A => scalar f(1), B => scalar f(2), C => scalar f(3) );
[download]

-- Randal L. Schwartz, Perl hacker

But you are still right to complain about the my. The name that is advertised in the debugging statement refers to a package variable and not to the variable actually being printed. This indicates some confusion. Plus my and mod_perl (tyop fix, had been CGI) when not understood correctly leads to lack of sharing which is a deep problem.

I know why it is a problem in Perl, and I think I have a sense of why there is no good fix for the problem, but I cannot articulate it very well.

For those who don't know, if you have a my around a sub and the my is executed multiple times, you then wind up with multiple copies of the my variable (one per invocation), and there are deep naming problems making it impossible to give a clean answer as to which copy of the my goes with the globally named sub.

Perl doesn't answer it, it just gives you a "Cannot stay shared" warning and proceeds to not do what you might expect. If you use my variables like globals in your script in mod_perl, you will hit this because mod_perl executes your script on each call. Execute it twice and now all of those global mys are not shared properly and you have serious voodoo.

This is a very good reason to be in the habit of using vars when you really are thinking of globals. (Based on first principles I would want to check in 5.6 whether carelessness with "our" could also hit this problem. I honestly don't know the answer.)

/tell tilly if anyone needs clarification on this.

I'm so sorry for the confusion I created with the way I labled my debugging scripts!

While I am using mod perl and the script interfaces several home grown object packages, the fact is that the References in this snippent are read by me as follows:


ChangeAdm::Review::Requestor = $Requestor
ChangeAdm = Current Script/package
Review = Current Subroutine
Requestor = The variable I'm debugging.


I hadn't considered the confusion that might have created.

my apologies.

coreolyn Duct tape devotee.

I've seen this bite people more than once (it bit me once). It makes me think => providing scalar context to its right-hand side would be a good enhancement. Of course, that probably won't happen since I've seen people feel gleeful about abusing => for things like kill INT=>@pids. ):

We could sneak it in by first adding a warning if the list context after => made a difference (wantarray was called, @array was evaluated, etc.). But that sounds quite difficult. Dang, I need that time machine again!

        - tye (but my friends call me "Tye")

Gotcha!

Thanks merlyn! What bites is this construct works in other places in the script... Man I've a lot of code to fix!

coreolyn Duct tape devotee.

I am still confused as all the variables in use are local to the snippet with the exception of the cgi query object $q

Why does the parameter store correctly when used as:
my $Requestor = $q->param('Requestor') but not when it is being packed in the hash?

Requestor=>$q->param('Requestor')
[download]

coreolyn Duct tape devotee.