Re^4: Possible for Map to create Hash of Hash?

[LanX]

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

[vsespb]

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.

[Anonymous Monk]

:D

OP-Q: I am using a knife to cut this steak, how can I use scissors?

You-A: As an alternative, you can use an improvised spork made of toothpicks, saves two characters!

[LanX]

++

Excellent metaphor! 8)

[runrig]

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)

[LanX]

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

Well the OP explicitly asked for HoHs and said " To create a hash that will allow me to determine if a store has a product I can use: "

I'm no native speaker, but for me this also reads like "if a store has products at all" which is quite complicated with a flat multi-dim hash.

I'm not banning multi-dim hashes both approaches have pro and cons.

[runrig]

Well the OP explicitly asked for HoHs and said " To create a hash that will allow me to determine if a store has a product I can use: "

I'm no native speaker, but for me this also reads like "if a store has products at all" which is quite complicated with a flat multi-dim hash.

To me it sounds like he just needs a store/product lookup and assumes that he needs an explicit HoH...but it is somewhat ambiguous, and things around here are not always clearly written, so let's just throw both solutions out there and let'em pick.