On 4/26/05, Otis Gospodnetic <[EMAIL PROTECTED]> 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 http://c2.com/cgi/wiki?FutureValue ) Which interestingly enough now seems to be implemented in Doug Lea's changes for Java 5 ( http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html ) Although without the asynchronous element, I guess it is just lazy initialization. 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 ( http://javanicus.com/blog2/items/178-index.html ) from for ( i in 0 ..< hits.length() ) { println(hits.doc(i)["filename"]) } into hits.each{ println(it.filename) } which has far less chances for making typos :-) jez. -- http://javanicus.com/blog2 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]