Lucene - Core
  1. Lucene - Core
  2. LUCENE-775

Searcher code creating Hits is somewhat messy

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New, Patch Available

      Description

      This patch makes sure all Hits-resulting queries sent to Searcher pass though the same methods, rather than an ad hoc Hits call per method call. Did it so it would be easier for me to implement this decorated searcher cache of mine.

      I could not find any implementations overriding the methods I set final, so I think it is allright.

      1. searcher.diff
        2 kB
        Karl Wettin

        Activity

        Hide
        Hoss Man added a comment -

        I agree that's messy and should be cleaned up .. while we're at it the Hits constructor has just as much redundency.

        i don't think it's safe to make those methods final though ... there may not be any subclasses in the tree, but that's no garuntee there aren't users with their own subclasses (consider all the people who might have written a proxy cache like you are but needed to override all of those methods to do so)

        can you explain this...

        + /** Sub class ad hoc IndexReader coupling */
        + protected IndexSearcher()

        { + }

        "reader" is package protected, so any out of package subclass that uses this constructor is pretty much screwed right? .. how is would this constructor be useful?

        Show
        Hoss Man added a comment - I agree that's messy and should be cleaned up .. while we're at it the Hits constructor has just as much redundency. i don't think it's safe to make those methods final though ... there may not be any subclasses in the tree, but that's no garuntee there aren't users with their own subclasses (consider all the people who might have written a proxy cache like you are but needed to override all of those methods to do so) can you explain this... + /** Sub class ad hoc IndexReader coupling */ + protected IndexSearcher() { + } "reader" is package protected, so any out of package subclass that uses this constructor is pretty much screwed right? .. how is would this constructor be useful?
        Hide
        Karl Wettin added a comment -

        > can you explain this...
        >
        > + /** Sub class ad hoc IndexReader coupling */
        > + protected IndexSearcher()

        { > + }

        >
        > "reader" is package protected, so any out of package subclass that uses this
        > constructor is pretty much screwed right? .. how is would this constructor be useful?

        Sorry, that is an old artifact from a hack, not ment for the patch. I'll refresh the patch.

        > i don't think it's safe to make those methods final though ... there may not be any
        > subclasses in the tree, but that's no garuntee there aren't users with their own subclasses
        > (consider all the people who might have written a proxy cache like you are but needed
        > to override all of those methods to do so)

        I personally think they should change their code to override only the non-final method call. Anything else would be overkill. At least that is what I concluded while making these changes, hence the finals. But if it is final or not does not matter much to me. It is all good as long all Hits-returining method calls pass by that last non-final method in this patch.

        Show
        Karl Wettin added a comment - > can you explain this... > > + /** Sub class ad hoc IndexReader coupling */ > + protected IndexSearcher() { > + } > > "reader" is package protected, so any out of package subclass that uses this > constructor is pretty much screwed right? .. how is would this constructor be useful? Sorry, that is an old artifact from a hack, not ment for the patch. I'll refresh the patch. > i don't think it's safe to make those methods final though ... there may not be any > subclasses in the tree, but that's no garuntee there aren't users with their own subclasses > (consider all the people who might have written a proxy cache like you are but needed > to override all of those methods to do so) I personally think they should change their code to override only the non-final method call. Anything else would be overkill. At least that is what I concluded while making these changes, hence the finals. But if it is final or not does not matter much to me. It is all good as long all Hits-returining method calls pass by that last non-final method in this patch.
        Hide
        Karl Wettin added a comment -

        More nasty old code I'm getting ridth of.

        Show
        Karl Wettin added a comment - More nasty old code I'm getting ridth of.

          People

          • Assignee:
            Unassigned
            Reporter:
            Karl Wettin
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development