Boosts might not make sense to become immutable, it might make the code too complex. Who is to say until the other stuff is fixed first. The downsides might outweight the upsides.
So yeah, if you want to say "if anyone disagrees with what the future might look like i'm gonna -1 your progress", then i will bite right now. Fixing the rest of Query to be immutable, so filter caching isn't trappy, we should really do that. And we have been doing it already. I remember Uwe suggested this approach when adding automaton and related queries a long time ago. It made things simpler and avoided bugs, we ultimately made as much of it immutable as we could. Queries have to be well-behaved, they need a good hashcode/equals, thread safety, good error checking, etc. It is easier to do this when things are immutable. Someone today can make a patch for FooQuery that nukes setBar and moves it to a ctor parameter named 'bar' and chances are a lot of the time, it probably fixes bugs in FooQuery somehow. Thats just what it is. Boosts are the 'long tail'. they are simple primitive floating point values, so susceptible to less problems. The base class incorporates boosts into equals/hashcode already, which prevents the most common bugs with them. They are trickier because internal things like rewrite() might "shuffle them around" in conjunction with clone(), to do optimizations. They are also only relevant when scores are needed: so we can prevent nasty filter caching bugs as a step, by making everything else immutable. On Thu, Apr 2, 2015 at 9:27 AM, david.w.smi...@gmail.com <david.w.smi...@gmail.com> wrote: > On Thu, Apr 2, 2015 at 3:40 AM, Adrien Grand <jpou...@gmail.com> wrote: >> >> 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? > > > The “if” part concerns me; I don’t mind it being a separate issue to make > the changes more manageable (progress not perfection, and all that). I’m > all for the whole shebang. But if others think “no” then…. will it have > been worthwhile to do this big change and not go all the way? I think not. > Does anyone feel the answer is “no” to make boosts immutable? And if so why? > > If nobody comes up with a dissenting opinion to make boosts immutable within > a couple days then count me as “+1” to your plans, else “-1” pending that > discussion. > > ~ David Smiley > Freelance Apache Lucene/Solr Search Consultant/Developer > http://www.linkedin.com/in/davidwsmiley --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
