lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
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.

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:cutting@apache.org]
> 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: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message