in reply to Re: Re: Re: Hash slices ?
in thread Hash slices ?

Poppycock! That is such an outrageous statement I don't really know where to start.

If we are to take "same as" in some comment in some sample code and extrapolate fundamental behavior from it... So since "same as" has such profound meaning, then it must also be true that these two are "the same":

@days{@x,@y} ($days{@x},$days{@y})
or even these:
@days{foo(),bar()} ($days{foo()},$days{bar()})
when in fact, they aren't.

The fact is that a hash slice in a scalar context returns the last item of the hash slice because there is C code that specifically does that. What you quoted doesn't qualify as documentation of that fact. If that is the only documentation, then it is undocumented.

In fact, Perl actually goes though and builds the entire list result of the hash slice and then moves the last item to the front:

unlike many "list-returning operations" that know to optimize their behavior in the face of scalar context. And all of this has very little to do with the comma operator which you claim it is "documented" as being "same as".

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

Replies are listed 'Best First'.
Re (tilly) 5: Hash slices ?
by tilly (Archbishop) on Apr 13, 2001 at 18:43 UTC
    There is a significant and important difference between how you are supposed to think about things and what goes on under the hood.

    merlyn is absolutely right about what concepts Perl's behaviour is intended to give. You are absolutely right about the implementation. It is both possible and likely that a future implementation will render your observation incorrect. It is much less likely that the concept both merlyn and perldata are trying to convey will be invalidated at a future point.

    Therefore I like merlyn's answer and do not consider it, implementation trivia notwithstanding, poppycock.

      *Sigh* It appears that you are mixing threads here. I didn't call "poppycock" any assertion by merlyn about "what concepts Perl's behavior is intended to give". I called "poppycock" his claim that "same as" is a reasonable way of documenting "same as, to the point of returning the same things when used in a scalar context".

      Update: See (tye)Re4: List context or not? for a better argument on this.

              - tye (but my friends call me "Tye")
        Your misjudgement of my intent notwithstanding, I answered in the right thread to the statement that I intended to respond to.

        Now you may wish the documentation to be clearer and more verbose.

        However the documentation is right. Optimizations notwithstanding, those two constructs are supposed to be the same as each other. Within Perl you are not supposed to be able to tell any difference. And when the documentation points to two constructs and says that they are the same, then they darned well better be the same in all contexts! Else the documentation is wrong. Which is why the documentation did not so document the case which is not the same in scalar context!

        As for the reasonableness or not of this interpretation, I can only speak for myself. Perhaps I read unusually closely, but on this item I distinctly remember when I originally encountered that documentation that I understood the phrase "the same as" and correctly figured out how it would behave in scalar context. Indeed you can see that in my tenth post here. Now why do I remember that? Because I remember looking at it and wondering what was different between the two that were not listed as being the same.

        So while you could certainly ask for clearer documentation of that fact, the documentation is supposed to be able to interpreted that closely. And in fact we have at least one real life example of someone who did just that.

        Now read what merlyn wrote, again. He never asserted that it is reasonably documented. He just said that it is documented and derivable from the documentation. Contrary to your assertion, that claim is not "poppycock".