I don't have CVS access and prefer the safety of not having it :) so I
don't
hose things up but wanted to suggest that a couple of classes/method be
slightly changed so that the modifiers go from the implicit
"package-private"
to public or protected.
In an earlier release I wanted to add a "SubstringQuery" that matches
search
terms that are substrings of words in the doc, so "framework" matches
"frameworks",
"singletonframeworks", and "framework" itself. My impl changed the boost
based
on how many extra chars the word in the doc has, so more exact matches
returned
higher scores.
I understand this is expensive but sometimes this is what a user wants.
I also see there's now a WildcardQuery that may do the job now for this
exact example
(via searching for "*framework*" I guess) but that's beside the point
-this refers
to all Query additions.
Problem is that on the org.apache.lucene.search pkg, some of the defs
require that any Query I want to write *has* to be in that pkg. Fine for
official additions to the code base, bad for experiments/decoupled
contributions.
Proposed solution is to change a couple of decls in Scorer and Query:
Scorer.java
make score() public
Query.java
make all methods public or protected (normalize,
sumOfSquaredWeights,prepare)
By doing this other Queries can be added w/o having to be in the above
package.
Nothing can possibly break by doing it :) and I don't think this is a
design/encapsulation
flaw to expose these.
So if there's no major objections by others or misunderstandings on my
part
could the powers of be make the above decl changes?
Thanks,
Dave
--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
don't
hose things up but wanted to suggest that a couple of classes/method be
slightly changed so that the modifiers go from the implicit
"package-private"
to public or protected.
In an earlier release I wanted to add a "SubstringQuery" that matches
search
terms that are substrings of words in the doc, so "framework" matches
"frameworks",
"singletonframeworks", and "framework" itself. My impl changed the boost
based
on how many extra chars the word in the doc has, so more exact matches
returned
higher scores.
I understand this is expensive but sometimes this is what a user wants.
I also see there's now a WildcardQuery that may do the job now for this
exact example
(via searching for "*framework*" I guess) but that's beside the point
-this refers
to all Query additions.
Problem is that on the org.apache.lucene.search pkg, some of the defs
require that any Query I want to write *has* to be in that pkg. Fine for
official additions to the code base, bad for experiments/decoupled
contributions.
Proposed solution is to change a couple of decls in Scorer and Query:
Scorer.java
make score() public
Query.java
make all methods public or protected (normalize,
sumOfSquaredWeights,prepare)
By doing this other Queries can be added w/o having to be in the above
package.
Nothing can possibly break by doing it :) and I don't think this is a
design/encapsulation
flaw to expose these.
So if there's no major objections by others or misunderstandings on my
part
could the powers of be make the above decl changes?
Thanks,
Dave
--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>