> > I'm tempted to simply make that change by default for 2.9, now. >
Agree ! Shai On Sun, May 24, 2009 at 1:28 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > On Sun, May 24, 2009 at 2:20 AM, Shai Erera <ser...@gmail.com> wrote: > > One thing I don't fully understand about actsAsVersion (and I know it was > > said that we may want to drop that approach) - for how long does it stay? > I > > mean, let's take the invalidAcronym. It is a change in back-compat, yes. > But > > for how long are we expected to support it? And if we decide to support > it > > for one minor release, or even one major release, will that ctor be > > deprecated? (I think it must be deprecated ...) > > Well, it's pretty clear actsAsVersion in any form (global static, > magically stored in index, passed in to ctors of those classes that > wanted to change settings) has too many objections, so this question > is somewhat moot. (Yet, if I had to guess, I think we'd want to > support it for longer than 1 minor release, especially for settings > that impact how your index is created). > > Forcing a decision on upgrading, by deprecating the old API, is I > think an adequate workaround in most cases. New users would not use > the deprecated API, and the javadocs would strongly call out which > default is preferred. Old users would see nothing change, except new > deprecations, and when they go to fix the deprecations they'd see what > setting to use to remain back-compat, and also realize what they are > foregoing by doing so. > > > Also, Mike - you suggested coming up with newer names to methods to > reflect > > new features (such as a boolean saying whether to score when you sort). > This > > is strongly related to our ability to add methdods to interfaces/abstract > > classes. If we add an abstract method to Searcher with the new boolean, > > we're breaking back-compat. > > Right, though I think on a case by case basis we are in fact willing > to break this, because the back-compat policy is not set in stone. EG > we've added new abstract methods to Searcher. > > Still, I think for 2.9 we have to migrate away from all interfaces. > EG we need a dedicated issue w/ migration patch, to move away from > Searchable. > > > Those specific problems (scoring when sorting) came into play only since > the > > introducation of the "fast and easy" search methods (which if you look at > > their signature - they are not so fast and easy anymore). If we had just > > search(Collector, Query) (and maybe a couple other variants which need to > > take into account more than just Collector and Query) you won't have that > > problem. > > But I think providing the sugar methods (that create TSDC or TFDC) is > important: > > search(Query query, int topN) > > search(Query query, int topN, Sort sort) > > Simple things should be simple; complex things should be possible. > > It's just that that 2nd method should by default do no scoring. Maybe > we could simply consider changing that default (w/o adding the new > API) for 2.9? > > > A reviewer, or anyone else will be required to first create a Collector. > > They read somewhere that TFC is used for sorting and that it has a bunch > of > > static create() methods. If they don't read it, they at least see a > sample > > somewhere. So they create a TFC and maybe they see a couple of > completions > > to create or not, but at least the changes are local to TFC. We can add > more > > create() variants to TFC w/o breaking back-compat, because TFC is not > > extandable. > > Sure, if we had no sugar methods then any wanting to do a search would > be forced to be fully explicit. But the power of good defaults is > you're not forced to go and make a bunch of decisions on settings that > have natural defaults. > > > Coosing the defaults of each create() is bound to whether we want the > > defaults to always reflect the best usage (which I prefer). At least in > the > > scoring example, I was under the impression we keep scoring for the sake > of > > back-compat, even if by changing it, it means nothing too bad will happen > > (we all kind of agree that scoring when sorting is useless, but because > of > > our back-compat policy we can't change it). I think there Grant's > proposal > > to decide on a case-by-case basis would have eliminated scoring when > sorting > > by default. > > Right, when sorting by field we should not score, by default. I'm > tempted to simply make that change by default for 2.9, now. When > compared to, say, changing IndexReader.open to return a readOnly > reader by default, which I think would mess up alot of apps, I think > not scoring by default when sorting by field will have much less of an > impact. > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
