[pylucene-dev] why isn't my custom Similarity objectchangingthebehavior?

[Andi Vajda]

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