If the non-public core requires a subclassible SegmentReader then
SegmentReader should certainly be made subclassible. But we shouldn't
make changes to improve the extensibility of the non-public API. That's
a slipperly slope. The fact that you can access package-protected
members by writing code in the same package is a loophole, not a
supported extension mechanism. We need to retain the freedom to change
non-public APIs without warning.
I'd love to see a good patch that adds an IndexReader.reopen() method
and I hope you are not discouraged from writing one.
Doug
Robert Engels wrote:
I can submit a patch to add the IndexReader.reopen() method.
BUT, I think the requested change to SegmentReader is still valid, for the
reasons cited in the previous email.
There is already support for replacing the SegmentReader impl at runtime
with System properties, but without the SegmentReader changes I think it is
next to impossible to have any worthwhile subclass - except for "maybe"
method logging, so either the runtime replacement code should be removed, or
the changes made. Currently there just isn't a way for the subclass to know
ANYTHING, since all of the initialization methods called by the static
factory method are private.
-----Original Message-----
From: Doug Cutting [mailto:[EMAIL PROTECTED]
Sent: Monday, May 01, 2006 6:03 PM
To: java-dev@lucene.apache.org
Subject: Re: SegmentReader changes?
Robert Engels wrote:
Correct - changing SegmentReader would be best, but in the past, getting
proposed patches included has been slower than expected.
I'm sorry if the process has been frustrating to you in the past. I
hope your experiences are better in the future.
So, by making the
SegmentReader more easily subclassed (which should hopefully get approved
quicker), I can still have a "build" of Lucene that does not require
patching any files. (just including classes in the appropriate package to
access package level vars/methods).
Aren't we discussing a change to IndexReader, adding a new method? This
is not a contrib module, but a change to the core. So proposing it as a
patch file that changes existing classes is the normal course. I don't
think we ought to be in the pracice of making changes in order to
support easier access to non-public APIs.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
