I'll open an issue for this and we can discuss under there. And I still need to open issues for the other "change defaluts" in my original email.
Mike On Sun, May 24, 2009 at 8:11 AM, Shai Erera <ser...@gmail.com> wrote: >> 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 >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
