in reply to Idea for XPath implementation

I know nothing about XPath, so take it for what it's worth, but this method of searching seems a bit backwards. That'd be like giving your OS of choice a file called /path/to/file, having the OS look for all files called 'file', anf for each one, seeing if it's in a directory called 'to', etc. If you have a heirarchical structure, best to make use of that fact and narrow your search quickly. A nested hash structure comes to mind for implementation...this way, you can see if $struct{colors}{paprika}{bad} exists, and have stored in that the value that you have listed above.

thor

Replies are listed 'Best First'.
Re: Re: Idea for XPath implementation
by Jaap (Curate) on Apr 01, 2003 at 20:03 UTC
    The disadvantage of building a hashtree is that it takes a lot of memory.
    Also, on an XPath query like //banana, you have to search every leaf to see if it is called banana.
      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

        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.