You're right, it can take a lot of memory. If you're concerned about it, use a tied DBM file. My experience with them is light, but from what I remember, at least one of them handles nested hashes. Also, I don't see why looking for //bananna would take long at all. If you've got all of your stuff in a hash, a simple print "found banana" if $hash{banana} would suffice, I think. Or, if you want it to be even cleaner, you could do something like this:
$hash{/banana} = 1.35;
$hash{/banana/shake} = 1.48;
$value = value("banana", "shake");
sub value
{
my $key = join "/", @_;
return $hash{/$key};
}
Like I said, though, I don't know anything about XPath, so I might be talking out of my hind quarter...:)
thor | [reply]
[d/l]
[select] |
We are talking about a TREE of hashes. This could look like this:
my $hashTree{'colors'}{'banana'} = 'yellow';
Now to find the bananas, the entire tree has to be searched through. | [reply]
[d/l] |
I still don't understand, unless the // syntax does not imply full path. Would it be possible to add a lookup table? A HoA comes to mind, keyed on leaf name, with the array values being the full paths to leaves with that name.
(code untested: also not robust. meant to be concept, not implementation)
my %lookup;
add_node("/colors/banana");
sub add_node
{
my $fullpath = shift;
my $leaf = (split '/', $fullpath)[-1];
push @{$lookup{$leaf}}, $fullpath;
}
I still don't see why you'd need to access banana without full path. Is the idea that you want to find all properties that a banana has? For example, if banana occurs in both the colors branch and flavors branch, you want to know that bananas have both color and flavor (you'd also know what color and what flavor it is, too)
thor | [reply]
[d/l] |