On 8/18/09 5:44 PM, Yonik Seeley wrote:
On Tue, Aug 18, 2009 at 8:01 PM, Michael Busch<busch...@gmail.com> wrote:
On 8/14/09 9:23 AM, Yonik Seeley wrote:
Another thing I was wondering about was the opacity of State - one
can't inspect or change the attributes w/o restoring it first.
Undesirable limitation, or feature allowing more flexible state
implementations?
Excellent point! This limitation is currently there to discourage changing
values of
a state, because that would be rather inefficient: you'd have to lookup the
attribute(s)
of each state you want to change.
Yeah, but restoring state also involves looking up attributes... so if
one is going to skip around a cached list of States (tokens), it can
still be more efficient to not restore each.
Right, for this the proposed StateContainer should help.
What I meant was that often caching of tokens is not necessary at all.
There were two
filters in contrib (ShingleFilter and another one I can't recall right
now) that did a lot
of token caching; I rewrote them in a way so that they do most of their
work on the
fly, without cloning/caching.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
