No, not at all. I will put something together. BUT, back to the subclassing comments... Why have the runtime replaceable support then in the SegmentReader factory - there is nothing useful a subclass can do at this time, and without API changes, it will never be able to.
-----Original Message----- From: Doug Cutting [mailto:[EMAIL PROTECTED] Sent: Monday, May 01, 2006 6:22 PM To: java-dev@lucene.apache.org Subject: Re: SegmentReader changes? 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
