On Thu, 15 Mar 2007, Ofer Nave wrote:
I just finished reading the README file very carefully, and figured out that I was unaware of a lot of crucual background. I read the example demonstrating a custom Analyzer class, and the section detailing what specific methods I need to implement to subclass Similarity.
Good ! (and having me on vacation, offline, for a week, helps too :) )
1) Did I implement the subclass wisely?
Yes
I only wanted to override tf(), but needed to implement many other methods in order to conform. I also didn't want to have to recode the existing logic of the superclass, and I didn't know how to properly call the super class methods, so instead I instantiatied the superclass in __init__ and delegated to it to calculate the answers for me. This works for state-less classes, but would be problematic if I was subclassing a class with state, where my subclass would have to share state with the superclass.
Sharing state with the superclass is not possible unless I implement a proper, implementation-aware, extension point. There is an extension point for Similarity, as you discovered, but not for DefaultSimilarity. But despair not, the Lucene way to do this is to use SimilarityDelegator which does pretty much what you just did anyway and there doesn't seem to be any state to share anway (in this context).
2) Python doesn't have declared/static types, so how does Java know which python idf() method to call?
It doesn't know. What happens behind the scenes in PyLucene is that your Similarity extension is recognized as such and wrapped with a Java subclass of Lucene's Similarity called PythonSimilarity. This class declares all Similarity extension methods as native. The C++ part of PythonSimilarity then makes the calls into Python and your methods.
Andi.. _______________________________________________ pylucene-dev mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
