Re: A question of style: Composite keys to multiple values

And... sure. It works. But the whole approach makes me want to disavow it. The right "value" should be a simple list (or sub-hash? seems unnecessary) containing both values. But using a "two strings smacked together" key just seems wrong. I'm just not sure what would ACTUALLY be simpler (for values of 'simpler' approximating "easier for a programmer to understand.")

Well, an in-memory database would be nicest, if there is an easy way to query it. And to be fast, it would build two indexes, which would either be b-trees or... *drummroll* hash tables.

But I wouldn't introduce such a big dependency for a relatively trivial feature.

So in the end I think it boils down to two hashes, which is the most pragmatic solution in Perl space.

It works, it isn't very complicated, it's easy to udnerstand for the reader -- what more do you want? Unless memory becomes scarce, I'd stay with the current solution.

Perl 6 - the future is here, just unevenly distributed

Comment on Re: A question of style: Composite keys to multiple values

Replies are listed 'Best First'.
Re^2: A question of style: Composite keys to multiple values by Voronich (Hermit) on Aug 06, 2012 at 20:15 UTC
Yeah ok. I'll buy most of that. I'm going to merge the values into a list, since there isn't really any need for multiple hashes like that, and the values need to resolve at the same point in the code. (It's not like there's any semantic difference in the usage at all.) The problem about elegance (or, more importantly: simplicity) is that this is the beginning of a code base that's going to be expanding rather a lot. I can see the additional exception logic and strange additional conditions coming in to pollute this, so I'm trying to nip it in the bud. But then I'm almost certainly playing "Premature Optimization" games. Thanks o/	[reply]

Replies are listed 'Best First'.

Re^2: A question of style: Composite keys to multiple values
by Voronich (Hermit) on Aug 06, 2012 at 20:15 UTC

Yeah ok. I'll buy most of that. I'm going to merge the values into a list, since there isn't really any need for multiple hashes like that, and the values need to resolve at the same point in the code. (It's not like there's any semantic difference in the usage at all.)

The problem about elegance (or, more importantly: simplicity) is that this is the beginning of a code base that's going to be expanding rather a lot. I can see the additional exception logic and strange additional conditions coming in to pollute this, so I'm trying to nip it in the bud.

But then I'm almost certainly playing "Premature Optimization" games.

[reply]