Lucene - Core
  1. Lucene - Core
  2. LUCENE-2052

Scan method signatures and add varargs where possible

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0
    • Fix Version/s: 3.0
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      I changed a lot of signatures, but there may be more. The important ones like MultiReader and MultiSearcher are already done. This applies also to contrib. Varargs are no backwards break, they stay arrays as before.

      1. LUCENE-2052_fa.patch
        0.7 kB
        Robert Muir
      2. LUCENE-2052.patch
        6 kB
        Uwe Schindler
      3. LUCENE-2052.patch
        7 kB
        Uwe Schindler

        Activity

        Hide
        Uwe Schindler added a comment -

        Is there any eclipse plugin/refactoring/cleanup that helps when doing this? Cannot find anything

        Show
        Uwe Schindler added a comment - Is there any eclipse plugin/refactoring/cleanup that helps when doing this? Cannot find anything
        Hide
        Uwe Schindler added a comment -

        Here a patch that adds more varargs where it makes sense (e.g. MultiSearcher ctor to pass Searchables, adding more than one sub query, merge boolean queries and so on - everywhere, where the array is not the meaning but more a unlimited list of parameters).

        If somebody finds something in addition, speak load!

        Show
        Uwe Schindler added a comment - Here a patch that adds more varargs where it makes sense (e.g. MultiSearcher ctor to pass Searchables, adding more than one sub query, merge boolean queries and so on - everywhere, where the array is not the meaning but more a unlimited list of parameters). If somebody finds something in addition, speak load!
        Hide
        Uwe Schindler added a comment -

        Updated patch, as there may be a backwards comp problem (but only if you recompile!) if you try to override a varargs method with an array param (which is not possible). Removed the varargs from docFreq(Term[]) because of that again.

        Also added changes.txt.

        Show
        Uwe Schindler added a comment - Updated patch, as there may be a backwards comp problem (but only if you recompile!) if you try to override a varargs method with an array param (which is not possible). Removed the varargs from docFreq(Term[]) because of that again. Also added changes.txt.
        Hide
        Robert Muir added a comment -

        uwe, here is one i found that got skipped in LUCENE-1987

        Show
        Robert Muir added a comment - uwe, here is one i found that got skipped in LUCENE-1987
        Hide
        Uwe Schindler added a comment -

        Thanks, I didn't check contrib.

        Show
        Uwe Schindler added a comment - Thanks, I didn't check contrib.
        Hide
        Robert Muir added a comment -

        Thanks, I didn't check contrib.

        I didn't really completely check, not sure really where we should have varargs there.
        (it does not make sense for stopwords to me, but then I feel all we need is Set<?> instead of file, varargs, hashtable, and all the other constructors we have)

        still i'd rather have consistency for now.

        Show
        Robert Muir added a comment - Thanks, I didn't check contrib. I didn't really completely check, not sure really where we should have varargs there. (it does not make sense for stopwords to me, but then I feel all we need is Set<?> instead of file, varargs, hashtable, and all the other constructors we have) still i'd rather have consistency for now.
        Hide
        Uwe Schindler added a comment -

        Yes, that's right. For stopwords a varargs ctor is not really "the right thing". Varargs are more for cases like instantiating a MultiReader with 5 IndexReaders or something like that. Or adding a bunch of clauses to a SpanQuery.
        The varargs Set<?> is one unit, arrays are not needed (they are there because of BW compatibility). All these ctors except Set<?> should have been deprecated in 2.9.

        Show
        Uwe Schindler added a comment - Yes, that's right. For stopwords a varargs ctor is not really "the right thing". Varargs are more for cases like instantiating a MultiReader with 5 IndexReaders or something like that. Or adding a bunch of clauses to a SpanQuery. The varargs Set<?> is one unit, arrays are not needed (they are there because of BW compatibility). All these ctors except Set<?> should have been deprecated in 2.9.
        Hide
        Uwe Schindler added a comment -

        Committed revision: 836248

        Show
        Uwe Schindler added a comment - Committed revision: 836248

          People

          • Assignee:
            Uwe Schindler
            Reporter:
            Uwe Schindler
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development