lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: [DISCUSS] Change Query API to make queries immutable in 6.0
Date Wed, 01 Apr 2015 19:25:52 GMT
I’m +1 to going all the way (fully immutable) but the proposal stops short
by skipping the boost.  I agree with Terry’s comments — what a shame to
make Queries “more immutable” but not really quite immutable.  It kinda
misses the point?  Otherwise why bother?  If this is about progress not
perfection, then okay, but if we don’t ultimately go all the way then there
isn’t the benefit we’re after and we’ve both changed the API and made it a
bit more awkward to use.  I like the idea of a method like cloneWithBoost()
or some-such.  A no-arg clone() could be final and call that one with the
current boost.

While we’re at it, BooleanQuery & other variable aggregates could cache the
hashCode at construction.

~ David Smiley
Freelance Apache Lucene/Solr Search Consultant/Developer

On Tue, Mar 31, 2015 at 11:06 AM, Adrien Grand <> wrote:

> On Tue, Mar 31, 2015 at 4:32 PM, Terry Smith <> wrote:
> > Thanks for the explanation. It seems a pity to make queries just nearly
> > immutable. Do you have any interest in adding a boost parameter to
> clone()
> > so they really could be immutable?
> We could have a single method, but if we do it I would rather do it in
> a different change since it would affect all queries as opposed to
> only a handful of them.
> Also there is some benefit in having clone() and setBoost() in that
> cloning and setters are things that are familiar to everyone. If we
> replace them with a new method, we would need to specify its
> semantics. (Not a blocker, just wanted to mention what the pros/cons
> are in my opinion.)
> --
> Adrien
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message