lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrien Grand <>
Subject Re: [DISCUSS] Change Query API to make queries immutable in 6.0
Date Thu, 02 Apr 2015 07:40:44 GMT
I did not close this door, I agree this is something that should be
considered and tried to list the pros/cons that I could think about.
However I would like it to be dealt with in a different issue as it
will already be a big change to change those 4 queries. Would would be
ok to first make queries immutable up to the boost and then discuss
if/how/when we should go fully immutable with a new API to change

On Wed, Apr 1, 2015 at 9:25 PM,
<> wrote:
> 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:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message