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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
