RE: Re: BrainPain-Help

Bleh - it was an entirely different problem. The problem is this (simplified):

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

In this code, function f is being invoked in a list context, and may return 0 or more items. This will really mess up the key/value pairing required for %x.

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

Comment on RE: Re: BrainPain-Help Select or Download Code

Replies are listed 'Best First'.
RE (3): BrainPain-Help by tilly (Archbishop) on Aug 10, 2000 at 20:16 UTC
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.	[reply]
RE: RE (3): BrainPain-Help by coreolyn (Parson) on Aug 10, 2000 at 20:31 UTC
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.	[reply]
<code>=></code> and list context; Re: BrainPain-Help by tye (Sage) on Aug 10, 2000 at 20:37 UTC
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")	[reply] [d/l] [select]
RE: RE: Re: BrainPain-Help by coreolyn (Parson) on Aug 10, 2000 at 20:07 UTC
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.	[reply]


No such thing as a small change
	PerlMonks