in reply to Re: Missing Hash Keys When Hash Created in Sub
in thread Missing Hash Keys When Hash Created in Sub

I can't decide -- is it more bug or programmer error? ;) Not using return offends my programming sensibilities at some level.

Dum Spiro Spero
  • Comment on Re^2: Missing Hash Keys When Hash Created in Sub

Replies are listed 'Best First'.
Re^3: Missing Hash Keys When Hash Created in Sub
by LanX (Saint) on Feb 23, 2015 at 23:45 UTC
    AnomalousMonk already pointed out that it's a hash bug and not depended on return, but ...

    > Not using return offends my programming sensibilities at some level.

    Many DSL constructs (read "sexy") are based on this "lispy" feature.

    In Ruby it's "super cool", don't wanna see the reaction if e.g. blocks in List::MoreUtils et.al. would require an explicit return.

    As always mixing apples and oranges leads to fruit salad. =)

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)

    PS: Je suis Charlie!

Re^3: Missing Hash Keys When Hash Created in Sub
by AnomalousMonk (Archbishop) on Feb 23, 2015 at 23:17 UTC
    ... more bug or programmer error?

    Bug. Definite bug. While implicit return is double-plus-unstyleful IMHO, construction of a hash with duplicated keys in list context per LanX's reply is (or ought to be) perfectly well defined and understood.


    Give a man a fish:  <%-(-(-(-<

Re^3: Missing Hash Keys When Hash Created in Sub
by Stringer (Acolyte) on Feb 24, 2015 at 00:11 UTC
    Heh, I agree. Still, it violates what I know about how subroutine return values are supposed to work.

      Going off topic here ... this reminds me of a problem on the final exam for my assembly language programming course in college. We were given a sample of code and asked questions about what it would do. Part of the program contained a JSR - jump to subroutine - instruction. But the code that was "jumped" to ended with an RTI - return from interrupt! I remember thinking .. you can't DO that! But of course, you can. And it had some useful result - removing two numbers from the stack instead of one (or vice versa) - a clever little hack that saved a step or two in the program. This bug showed a similar symptom - loss of data in returned values - but I doubt the cause is the same. But it gave me a chance to tell a story about learning the difference between what my mental model thought code did and what it actually did!

      Dum Spiro Spero