lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: SegmentReader changes?
Date Mon, 01 May 2006 23:22:14 GMT
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.


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 []
> Sent: Monday, May 01, 2006 6:03 PM
> To:
> 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:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message