Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=ix.netcom.com;
  b=nHswmixLSeyzXQ1r479vnitKzEyuy6PhCEgHYfjzArVoKJ12Ov8LdtpWbDTq+WQW;
  h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <473360E3.7030102@apache.org>
References: <47310D48.8030100@manawiz.com> <47321167.508@apache.org>
 <1194518633.31970.1220210729@webmail.messagingengine.com>
 <47334FC2.6050809@apache.org>
 <5EBAA21C-E4DA-40EC-AA50-CDD0482B2AA9@ix.netcom.com>
 <473360E3.7030102@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7A738AA9-AB85-4A96-87E1-332F5E52E422@ix.netcom.com>
Content-Transfer-Encoding: 7bit
From: robert engels <rengels@ix.netcom.com>
Subject: Re: Term pollution from binary data
Date: Thu, 8 Nov 2007 14:11:22 -0600
To: java-dev@lucene.apache.org

I was thinking of more along the Java ImageIO ImageRead/WriteParam  
stuff.

class IndexReaderParam {
	get/set UseLargeBuffers()
	get/set UseReadAhead();
	.. etc. other "standard" options, a particular index reader if free  
to ignore them ...
}

a custom IndexReader would create a custom CustomIndexReaderParam class.

class CustomIndexReader {
	void setIndexReaderParam(IndexReaderParm p) {
		CustomIndexReaderParam cp;
		if(p instanceof CustomerIndexReaderParam) {
			cp = (CustomIndexReaderParam)p;
		} else {
			cp  = new CustomIndexReaderParam(p);
		}
		... set params ...
	}
}

class CustomIndexReader extends IndexReaderParam {
	get/set CacheTerms
	.. etc..

	CustomIndexReader(){}
	CustomIndexReader(IndexReaderParam p){
		set super properties from p
	}
}


I don't really like the get/set name/value pair stuff. You end  
needing to define constants, etc. Make reading code much more  
difficult, and refactoring harder. It also makes generating the  
javadoc for the API much more difficult.

On Nov 8, 2007, at 1:17 PM, Doug Cutting wrote:

> robert engels wrote:
>> I think it would be better to have IndexReaderProperties, and  
>> IndexWriterProperties.
>
> What methods would these have?
>
> The notion of a termIndexDivisor is specific to a particular  
> IndexReader implementation, so probably shouldn't be handled by a  
> generic IndexReaderProperties.  This case is even stronger for  
> things like merge and deletion policy-specific properties.  We'd  
> like folks who implement a new policy or a new IndexReader to be  
> able to add new properties without having to add new methods to  
> IndexReaderProperties.
>
> So if all that's in IndexReaderProperties is generic stuff like  
> #getInt(String), with nothing IndexReader-specific, then why not  
> use a generic class like LuceneProperties, with all specific  
> setters and getters on the classes they're specific to.  Does that  
> make sense?
>
>> Just seems an easier API for maintenance. It is more logical, as  
>> it keeps related items together.
>
> Without more examples, I don't see this to be the case.  My goal is  
> that if someone adds a new parameter for a new implementation  
> that's not in Lucene's core, they should be able to add setters and  
> getters there, without altering the core, keeping related items  
> together.
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>


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