late binding behavior in hash definition

Replies are listed 'Best First'.
Re: late binding behavior in hash definition by merlyn (Sage) on Nov 22, 2000 at 18:37 UTC
This is straightforward to predict when you separate what's happening on the right side from what's happening on the left. The list of `(1 => 2, 3 => $x{1} )` [download] Is identical to `(1, 2, 3, undef)` [download] as long as `%x` didn't have a previous value. In fact, it's the prior value of `$x{1}` that you see, as evidenced by: `%x{1} = "old x sub 1"; %x = ( 1 => 2, 3 => $x{1} );` [download] The question for me is, why did you find this surprising or baffling? It's extremely consistent with what Perl does at all times: evaluate the right side of the assignment before altering any structure on the left. It's what permits `@a = (2, @a)` [download] or `@a = reverse sort @a;` [download] to work. -- Randal L. Schwartz, Perl hacker	[reply] [d/l] [select]
Re: late binding behavior in hash definition by Dominus (Parson) on Nov 22, 2000 at 19:29 UTC
You might as well ask why the right-hand side of `$x = ($x + 18) / 7;` [download] does not take into account the value that you are trying to assign, before it is computed, and set `$x` to 3.	[reply] [d/l]
Re: Re: late binding behavior in hash definition by japhy (Canon) on Nov 22, 2000 at 19:38 UTC
Are you kidding? Mathematical expansion like that would kick ass. `japhy` -- Perl and Regex Hacker	[reply]
Re: Re: Re: late binding behavior in hash definition by Dominus (Parson) on Nov 22, 2000 at 21:29 UTC
I'm not kidding. Some languages have something a little like that. But you quickly get into big problems. Consider: `my $x = not $x; my $y = $y-1;` [download] or `my @a = (@a, 3);` [download] for example.	[reply] [d/l] [select]
Re: late binding behavior in hash definition by gaspodethewonderdog (Monk) on Nov 22, 2000 at 18:45 UTC
I'm not exactly sure what you are trying to prove here, but in the first instance where you are creating the hash to assign to %x, I believe that you cannot do that assignment because until that code has finished executing everything after "%x =" is at the time an anonymous hash. After perl constructs the anonymous hash then the reference gets assigned to %x. To illustrate this... CODE: `use Data::Dumper; %x = ( 3 => 4, 1 => 5 ); print Dumper(\%x), $/; %x = ( 1 => 2, 3 => $x{1} ); print Dumper(\%x), $/;` [download] OUTPUT: `$VAR1 = { 1 => 5, 3 => 4 }; $VAR1 = { 1 => 2, 3 => 5 };` [download] The reason that $x{3} is assigned the 5 is because the new hash we are building for %x hasn't been finished yet and since it is an anonymous hash it still cannot be addressed. Therefore it goes and uses the previously defined %x to set $x{3}. Something I don't know about though is if there is a notation for within an anonymous hash to have it be able to reference itself. That way you could use this behavior to set other values based on itself while it is building. I also remember reading a while back that hashes are constructed backwards (somebody would have to verify this because I'm not 100% sure) so it is possible that even if you could do this it would probably be a little confusing. I'm not sure what you are getting at about the %y values being immediately bound after each statement is run because if this behavior didn't exist it would be impossible to code in perl because everything would be contingent on side effects which is a rather scary thought. After each semi-colon perl really ought to have moved all the bits around in the way I told it to. Cool find though... I certainly never would have bothered to try and access a hash's data while constructing the hash itself. On the other hand it probably isn't the best coding practice either, but what the hell!	[reply] [d/l] [select]
Re: late binding behavior in hash definition by frankus (Priest) on Nov 22, 2000 at 18:53 UTC
As I see it, this has little to do with hashes at all. Simply put it is a bit like trying to declare two variables thus: my ($a,$b)=(25,$a/5); print "$a and $b\n"; Hopefully that looks immediately wrong. For the reasons everyone has indicated above. Sorry, I was using this as an opportunity to approach answering questions in a simple fashion, some day I may have to teach Java Developers how to program (a real language)?. -- Brother Frankus.	[reply]
Re: late binding behavior in hash definition by japhy (Canon) on Nov 22, 2000 at 19:03 UTC
I had a post about this (somewhere, I have no clue what it was called). I'd like something like: `%hash = ( a => 1, b => 2, c => $_{a}, d => $_{b}, );` [download] Where `%_` is a magically bound hash which relates specifically to the hash being defined at the moment, and undergoes run-time magic. (It's not going to happen.) `japhy` -- Perl and Regex Hacker	[reply] [d/l]
(tye)Re: late binding behavior in hash definition by tye (Sage) on Nov 22, 2000 at 20:48 UTC
I'll jump right to the elegant solution to japhy's question: RE: multiple keys - one value - tye (but my friends call me "Stupendous Search")	[reply]
Re: late binding behavior in hash definition by Blue (Hermit) on Nov 22, 2000 at 18:45 UTC
princepawn, I think that's Perl trying to do the right thing. In your %x hash example, you are defining %x, As such, $x{1} is not defined until you finish defining %x. It's an atomic transaction. So trying to access it before it was defined gives you an undef. This seems like correct behavior. In your later example, you are refering to an already existing $y{1}, so you can access it's contents. =Blue ...you might be eaten by a grue...	[reply]

output

commentary