Erik Hatcher wrote:
I think, though I'm not speaking for anyone here but myself, that the
Lucene team is open to API improvements that _do not adversely affect
performance_ and that have _a real benefit_.
While I'm as IoC and design pattern savvy as the next developer, I'm
also highly pragmatic. I've not been convinced by any of the examples
thus far. If a unit test needs to detect if a document has been
added, you can check the size of the index before and after for
example, rather than doing some mock trickery to hook the addDocument
call. Or you could use AspectJ to do this if you really wanted to get
fancy. The unit test example shown is really a unit test appropriate
to Lucene itself, and not to a project using Lucene, it seems.
Pragmatically, have you ever had addDocument fail? If not, then what
peace of mind are you getting from such a test?
Ultimately, though, the decision to refactor the codebase to use
interfaces more pervasively lies with Doug.
Erik
I have seen this and several other similar requests dismissed with
similar reasoning. I, myself, once made similar requests of the abstract
classes in the analysis package. Yes, there are lots of ways to skin a
cat, but I would ask that a different question be asked, "'What is
risked in giving the flexibility to the user base to do it their way?"
These requests are often simply an appeal for flexibility. I can
understand the maintainers concerns about increasingly non-uniform use
of the API and associated cost of helping those experimenting. I don't
know how comfortable the maintainers are with simply letting these
people work it out for themselves or with the help of others in the
forum, but I hope these concerns are weighed against the possible
benefits to the people doing the myriad and sundry things they do with
open source projects. Flexibility is a real benefit.
Cheers,
Todd VanderVeen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
