in reply to LVALUEness in flattened hashes

  1. This certainly seems like the expected behavior (didn't look for documentation). The aliasing tricks happen with arrays and scalars as well. Why shouldn't it work with hashes in a list context? As for the keys not changing, I wouldn't expect them to since this would mean the key would need to be rehashed and possibly moved to a different bucket. It's easier to just make it unmodifiable.
  2. Wouldn't you expect the same behavior if you just used $h{'a'} or @h{qw(a c e)}?
  3. It'd surprise the hell out of me if it didn't behave this way.

antirice    
The first rule of Perl club is - use Perl
The
ith rule of Perl club is - follow rule i - 1 for i > 1

Replies are listed 'Best First'.
Re: Re: LVALUEness in flattened hashes
by calin (Deacon) on Jan 09, 2004 at 20:18 UTC
    Wouldn't you expect the same behavior if you just used $h{'a'} or @h{qw(a c e)}?

    Yes, I would expect that (I thought about this before posting). Assigning to $h{x} is ... the way to set a hash element. Also assignments to hash slices are common and widespread. But, could you show me any published code (CPAN module, etc., even obfu will do) that uses the lvalueness properties of a flattened hash? Would you rely on this in your own code?

    It'd surprise the hell out of me if it didn't behave this way.

    Flattened hashes were read-only lists created on the spot, on my mental map, until I found otherwise. It makes sense to me - and it doesn't. It's somewhere on the borderline. That's why I'm seeking wisdom.

    Also, please note, the point of my OP is not about arguing that Perl should do this or that -- all expressed opinions are IMHO. I'm just seeking an authoritative answer.

    To conclude, your opinion falls into for the sake of consistency, right?

      ... could you show me any published code (CPAN module, etc., even obfu will do) that uses the lvalueness properties of a flattened hash?

      Unfortunately, no code that uses the lvalueness properties of a flattened hash comes to mind. I think this is due to the fact that values and slices provide both lvalues and a list that is at longest half the length of just %h.

      Would you rely on this in your own code?

      In all truth, no. This is mainlydue to the fact that I would use values or slices instead.

      Also, please note, the point of my OP is not about arguing that Perl should do this or that

      If I came across as argumentative, I apologize.

      To conclude, your opinion falls into for the sake of consistency, right?

      Somewhere in there. I think it's behaving somewhat like a list of scalars with every "odd" one (as you put it) an unmodifiable value that doesn't die when you attempt to modify it. If that qualifies as "for consistency" then yes. I cannot think of a reason why you wouldn't offer it when the facilities for it are available. Furthermore, aliasing the values is less expensive than copying to a read-only list.

      antirice    
      The first rule of Perl club is - use Perl
      The
      ith rule of Perl club is - follow rule i - 1 for i > 1