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
