in reply to LVALUEness in flattened hashes
To do otherwise would be inefficient. We1 make copies of the keys because we have to (since hash keys aren't even scalars, they are simple strings).
Most of the time, whether we put aliases2 of values into the flattened list doesn't matter so why go to extra effort to make copies of each value (whether they be read-only copies or lvalue2 copies but certainly not LVALUE2 copies3).
It certainly would surprise me if flattened hashes didn't contain aliases, but that is mostly because of what I wrote above, which probably disqualifies me for that test.
I was certainly surprised that values didn't return aliases and that I had to resort to @hash{keys %hash} instead of values %hash until recently.
And it is consistant (as much as is possible) with flattened arrays. But the values are inconsistant with the keys in the same regard.
So I think the strongest argument is efficiency (which may have been an "accident" of an efficient implementation or may have been a designed efficiency -- you'll probably have to find the author to know for sure).
1 Not that I'm taking any credit for the implementation.
2 I'd replace most of your uses of "LVALUE" with "alias". lvalues can be assigned to (end of definition). LVALUEs are magic lvalues that copy any changes made to them to some "original" (or part of it).
:lvalue subroutines may muddy the water by returning aliases (I'd test but that feature appears to be quite broken in my moderately old versions of Perl), but their name indicates the function can be used as an lvalue. Common sense says that such is only useful if the changes get propogated back. Whether they get propogated back via the use of aliases or LVALUEs is an implementation detail.
So I wouldn't use "lvalue" (nor "LVALUE") to mean "assigments propogate back" since the former doesn't always imply that and the latter is a specific special case of it. (Which leaves us two terms for the two cases and no umbrella term, but I don't mind.)
3 Though recent changes make me think that we might end up with LVALUE values in the case of flattened tied hashes. Oh my!
|
|---|