Should be possible to introspect on Query objects

[richard]

In particular, it should be possible to determine the operator performed by the "top-level" query in the query object, get a list of the subqueries, get any appropriate parameters supplied (eg, valno and end of range for a VALUE_RANGE query, window size for a phrase query, etc) and get the term, wqf and position for a leaf query.

This API will necessarily involve quite a few methods - we need to make sure that it is no more complicated than really necessary, and be sure that it doesn't expose internals of the query representation (preventing us modifying these in future).

One particular issue is that we can't easily just return the "operator" used in the query, because leaf queries use a special "magic" value for the operator parameter. There are several solutions to this: 1) make OP_LEAF public. 2) make "get_operator()" return -1, and just document that it does that, 3) add an "is_leaf()" method, and document that get_operator() shouldn't be called unless "is_leaf()" returns false.

[richard]

(reassigning to nobody, since I don't think Olly's likely to be working hard on this right now, and nor am I.)

I forgot to mention two reasons for wanting this support:

1. Somebody asked recently on the mailing list for a way to display a human-displayable explanation of a query (ie, user-visible). This could be put together with the information available from this introspection interface.

2. Fixing bug #157 requires keeping track of the valuenumber for value range queries. Being able to get this out of the query would be the best approach: since the queryparser is internal, it can get the valuenumber directly from the internals, but it seems wrong for the queryparser to depend on internal hooks; it's reasonable that other people might want to write query parsers, so there shouldn't be anything special that our query parser does that other query parsers couldn't do.

[richard]

Sketch of some of the API required for this