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

Reply via email to