Hang Li wrote: > Why there are so many final and package-protected methods?
The package private stuff was motivated by Javadoc. When I wrote Lucene I wanted the Javadoc to make it easy to use. Thus I did not want the Javadoc cluttered with lots of methods that 99% of users did not need to know about. So a problem is how to distinguish methods that are meant for end users from those that only may rarely be needed by an expert developer. Perhaps we could establish a Javadoc convention for those methods that most users don't need to know about. For example, their documentation could begin "Expert:" or something. What do folks think of that? Also, many package private methods really are internal methods that are not designed to be called outside of the implementation. Trying to override them probably won't work. When stuff that is tricky to use is documented and easy to use, folks will use it, it won't work, and they'll complain, wasting everyone's time. So we must be careful about what is made public. I would rather err on the side of exposing less than more--folks who know what they're doing can always add code into a lucene package. It's not ideal, but it works. Some 'final' declarations made a performance difference when javac did inlining, but no longer do, and should probably be removed now. Some still keep people from subclassing things that are not designed to be subclassed. So these should also be considered on a case-by-case basis. > I want to change the way TermQuery doing scores. Could you please make a proposal to the lucene-dev list of which methods and classes should be made public or protected or non-final, and what documentation should be added? Thanks, Doug -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
