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 boosts?
On Wed, Apr 1, 2015 at 9:25 PM, david.w.smi...@gmail.com <david.w.smi...@gmail.com> 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 > 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 >> > -- Adrien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
