Re: Re: LVALUEness in flattened hashes

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?

Comment on Re: Re: LVALUEness in flattened hashes

Replies are listed 'Best First'.
Re: Re: Re: LVALUEness in flattened hashes by antirice (Priest) on Jan 09, 2004 at 20:50 UTC
... 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	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: Re: LVALUEness in flattened hashes
by antirice (Priest) on Jan 09, 2004 at 20:50 UTC

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

[reply]
[d/l]
[select]