: Is there a reason for writers to be created via the constructor and : the readers to be created via the static scope?
I wasn't arround when those APIs were created, but i believe the main reason for the static IndexReader.open method was to deal with the unknown question: will this be a SegmentReader or a MultiReader ? In essence, it is the factory pattern -- but "poorly" implemented as a static method (i say "poorly" because it's a subjective opinion) IndexWriter on the other hand was implemented with a simpler constructor API since it doesn't have these issues. (I suspect once upon a time IndexReader worked the same way, and the public constructor was removed once the static method was added -- but i haven't verified this in the anals of commit logs) : Would it not be much more beautiful and object oriented to handle : this using factory methods in Directory? Or perhaps even one layer i agree with you that it would be nice if Factory patterns were used more (and more consistently) ... but i'm not sure if Directory is the right place to put them .. in theor a Directory is a purely abstract data storage object that doesn't evne know it contains an index. I could arguable wnt to use the same Direcotry object to construct an IndexWriter, an IndexReader and to store ancilary data i want to store using the openInput method. I do like the spirit of your patch -- but I don't see any reason not to go about solving the same problem using IndexReaderFactory and IndexWriterFactory interfaces, with things like IndexReader.open delegating to the "default" IndexReaderFactory (specified by a system property or something) for backwards compatibility. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
