: Lucene has historically taken the exact opposite approach... open up the API
: as needed. Unless there is very good reason for it, classes and data should
: be kept private.
Just to clarify the reasoning behind this: once something is made public,
the API has to be supported in perpetuity --
Cedric,
On Sep 17, 2007, at 11:54 AM, Erik Hatcher wrote:
On Sep 17, 2007, at 6:51 AM, melix wrote:
I've faced the very same problem with NearSpansOrdered and so on.
I think
unless there is a very good reason for it, classes should be made
public,
this would at least make the "delegate" d
On Sep 17, 2007, at 6:51 AM, melix wrote:
I've faced the very same problem with NearSpansOrdered and so on. I
think
unless there is a very good reason for it, classes should be made
public,
this would at least make the "delegate" design pattern available.
Lucene has historically taken the
on.
>>
>> Basically, in a SpanOrQuery, I am not able to find out what matched. Have
>> any of you faced that kind of problem, and found out an elegant way to do
>> it
>> without having to completely rewrite each getSpans() method
; any of you faced that kind of problem, and found out an elegant way to do it
> without having to completely rewrite each getSpans() method for all types of
> queries (this is basically what was done in a previous version of the
> application) ?
>
> Thanks,
>
> Cedric
>
vious version of the
application) ?
Thanks,
Cedric
--
View this message in context:
http://www.nabble.com/Span-queries-and-complex-scoring-tf4422915.html#a12615745
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
