: > : When custom Scorers and/or Directories need a close method, it can
: > : also be provided by subclassing Scorer, IndexSearcher and Directory
: > it seems like that would handicap adoption of new Queries/Directories ...
: > I don't know how many people would have been interested in
: > ConstantScoreQuery or FunctionQuery if they'd been told they had to stop
: > using IndexSearcher and start using a new "ConstantScorableIndexSearcher"
:
: Iirc no (general) closing method in Scorer or IndexSearcher was needed
: for the Constant... and Function... queries and scorers.
that's kind of side stepping my point: those classes gained popularity and
use because they were easy to adopt -- they didn't have any complex
dependencies, and could be droped into an existing Lucene application and
be used without any other changes. If they *had* needed maintain
resources, and that had forced the creation of custom IndexSearchers, no
one would have ever tried them out -- hence my point that your suggested
workarround would handicap the creation of new more complex Scorers and
Directories.
The bottom line is:
1) TermDocs has a close method
2) anything implimenting TermDocs should be able to trust that
close() will be called
3) anything iterating over a TermDocs should call close()
...ergo: TermScorer needs a close() method, right?
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
