On Fri, 25 Aug 2000, Quim Sanmarti wrote:
> I just stopped being a pain about operator precedences or n-arities. It was
> not the point. The point is, I believe, that the search query framework
> should be as independent as possible from the user query language.
I don't know. Personally, I prefer the idea that the operators are
implemented separately. It seems a bit odd that to add a "near" operator,
you'd need to edit the query parser and other files. That's why the
ParseTree subclasses implement operators/methods.
The retrieval of results from the database should clearly be separate from
parsing the user query. But, for example, why should AND result merging
be implemented in a different file? Granted, in the ParseTree classes, if
you wanted the boolean method to change, you'd need to change code there
too. But I like the idea that all the code for AND functionality is in one
file.
To say it a slightly different way, I think queries for an individual word
should be separated off, say into WeightWord or ResultList or a Searcher
class. I think each operator should have its own file and the "boolean"
parser be separate still.
For more details on the derivation, see the thread starting at the end of
March: <http://www.htdig.org/htdig3-dev/2000/03/0146.html>
and Andrew's response <http://www.htdig.org/htdig3-dev/2000/03/0151.html>
I'm hardly tied to this particular implementation. If someone wants to
write out a user query parser, I'd be glad to take it--mine is admittedly
buggy. I'd rather be concentrating on the backend work (including the
caching).
-Geoff
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
