On Thu, Dec 3, 2009 at 3:59 AM, Uwe Schindler <u...@thetaphi.de> wrote:
> I already wrote an comment in the flex issue about that. Its not really
> good. Maybe we should change the FilteredTermsEnum also to require calling
> next() first, which makes it more useable like an iterator.
+1
> I was always not
> so happy with the fact, that you need to have the strange do...while loop.
>
> For NRQ, the change is simple, just remove the next() call in the ctor. For
> other FilteredTermsEnums its similar, just move the seek code to the first
> next call.
>
> In my opinion, code should look like that:
>
> TermsEnum te = MTQ.getTermsEnum();
> TermRef term;
> while ((term = te.next()) != null) {
> ..
> }
Let's remove the .empty(), and let's switch to this "normal iterator"
semantics -- I think I had originally added that back when TermsEnum
didn't have a .term() method, ie, you had to keep the result returned
from calling .next() or .seek(). But that proved too much of hassle
(lots of places where we pass a TermsEnum down and the callee needs to
figure out what term it's on), so I've since added .term().
Actually TermEnum (the current API) already behaves like a normal
iterator, right? It's only FilteredTermEnum (and, FilteredTermsEnum)
that pre-next's itself on construction. So we should fix
FilteredTermsEnum to not pre-next, and to remove its empty() method?
Uwe do you want to take a stab at it? Or, I can... let me know.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
