lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Rayner <>
Subject Re: svn commit: r164695 - in /lucene/java/trunk: CHANGES.txt src/java/org/apache/lucene/search/ src/java/org/apache/lucene/search/ src/java/org/apache/lucene/search/ src/test/org/apache/lucene/
Date Tue, 26 Apr 2005 08:03:35 GMT
On 4/26/05, Otis Gospodnetic <> wrote:
> Also, is "a future for a hit" a typo, or does that actually mean
> something?  This makes me think of Python's "future", but I'm not sure
> what this means in this context.

My feeling originally was that as the obtaining of the document 
was expensive, a Hit should be a bit like the 'Future Value' pattern,
where a Hit is just a promise to delve into Hits with a certain index
at some point in the future.
( see )  
Which interestingly enough now seems to be implemented in Doug Lea's
changes for Java 5
( )

Although without the asynchronous element, I guess it is just lazy

An alternative implementation of Hit could be a 'Virtual
Proxy(GOF:207)' that stores
a delegate FutureHit or ActualHit, the FutureHit could be the starting
position, but after any call the delegates reference is swapped over
to ActualHit.  This would eliminate the check of 'resolved' at the start
of each method, and therefore increase perfomance.  However a memory
overhead would be incurred for the overhead of having three classes
instead of one.
So it's a better perfomance vs less memory usage tradeoff.

Thanks for allowing this change, it has now turned my previous Groovy example
( ) from

for ( i in 0 ..< hits.length() ) {



which has far less chances for making typos :-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message