lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Engels" <reng...@ix.netcom.com>
Subject RE: SegmentReader changes?
Date Mon, 01 May 2006 23:27:17 GMT
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:cutting@apache.org]
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: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


---------------------------------------------------------------------
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