Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Message-ID: <40AC976E.5060804@detego-software.de>
Date: Thu, 20 May 2004 13:33:02 +0200
From: Christoph Goller <goller@detego-software.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031009
MIME-Version: 1.0
To: Lucene Developers List <lucene-dev@jakarta.apache.org>
Subject: Re: TermInfosReader.getIndexOffset javadoc and code inconsistent?
References: <1085019974.4081.12.camel@vitabrits.panscient.com>
In-Reply-To: <1085019974.4081.12.camel@vitabrits.panscient.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Nigel Tao wrote:
> This is a minor quibble, but are the javadocs and the code for
> TermInfosReader.getIndexOffset(Term) inconsistent?  The javadocs say
> "less than" but the code says "less than or equal to" (if the "return
> mid" route is taken, which requires that term.compareTo(indexTerms[mid])
> == 0).

You are right. I have fixed the Javadoc.

> 
> But more importantly - does this impact any consumers of this method -
> if, for example, they actually presume "less than" rather than "less
> than or equal to"?

Not as far as I know. I fact it was the reason for a recent bug in the
skipTo implementation that I fixed some weeks ago.

> 
> Also, this may be a strictly academic point, but should it be documented
> that this method may return -1 if no index entry is <= term?  In
> practice this is impossible since indexTerms[0] is always the empty Term
> with "" field and "" text, which is less than (or equal to :-) any other
> Term.

Propose an improved Javadoc and I will commit it.

You already dived quite deep into the code.
There is a lot to learn from Doug :-)

regards,
Christoph


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org