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 http://www.linkedin.com/in/davidwsmiley On Tue, Mar 31, 2015 at 11:06 AM, Adrien Grand <jpou...@gmail.com> wrote: > On Tue, Mar 31, 2015 at 4:32 PM, Terry Smith <sheb...@gmail.com> 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: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
