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).

                - tye

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!

In reply to Re: LVALUEness in flattened hashes (efficient) by tye
in thread LVALUEness in flattened hashes by calin

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.