It's joined again with "\034" (by default)
You will be able to access this hash from other code using $h{$store,$product}. It's easier to write than $h{"$store $product"}
If, later, you decide that store can have spaces in its name, you will rewrite your first split code, but you won't have to rewrite $h{$store,$product} in other places.
Anyway, you can ask topic starter why he need split, while he just needs to
to determine if a store has a product
| [reply] |
> Anyway, you can ask topic starter why he need split, while he just needs to
> > to determine if a store has a product
With the nested approach he can also use things like keys %{$hash{$store}} to list all products.
The delimiter approach is a nice idea, but is neither shorter to write nor more efficient.
Cheers Rolf
( addicted to the Perl Programming Language)
| [reply]
[d/l] |
he can also use things like keys %{$hash{$store}} to list all products.
Agree. But does he need to?
neither shorter to write
It's shorter to write: "$h{$s,$p}" 9 characters. "$h{$s}{$p}" 10 characters. + code to populate hash is simpler.
nor more efficient
Maybe memory usage is not important in this case? And maybe serialization/deserialization time is more important. Who knows.
Also, perl has a special notation for it. That makes me think it's a useful feature for some cases.
| [reply] |
With the nested approach he can also use things like keys %{$hash{$store}} to list all products.
If the OP doesn't need it, then no need to do it that way.
We have no way of knowing if that's what the OP needs, maybe they don't know about the other solution. It's much more memory efficient than nested hashes, so is better when you don't need the nested hashes. It's best to know the pros and cons of both ways. I used the alternate solution just the other day to store 100,000's of what would have been nested several layers deep hashes, and I did not need to use keys or values or each. I just needed a quick lookup for a group of several different values.
The delimiter approach is a nice idea, but is neither shorter to write nor more efficient.
Also, this:
$hash{$product,$code} = 1;
Is very slightly shorter than this:$hash{$product}{$code} = 1;
And the first requires only one hash lookup, while the second requires two. Not to micro-optimize or anything though...(and I'm not going to bother benchmarking the difference between joining two strings and looking up a hash value...at least not today, anyway) | [reply]
[d/l]
[select] |
.. Anyway, you can ask topic starter why he need split, while he just needs to
I'm sorry, but you've missed my point :) I am questioning the wisdom of your suggestion for an alternative approach.
Since OP already decided on a hash-of-hashes, why switch back to a simple hash? Or hash-of-array-?emulation?
Why throw away the benefits of easy lookup?
There has to be some benefit to doing it differently; and few drawbacks
| [reply] |