[pylucene-dev] Re: PyLucene port to Ruby

Andi Vajda vajda at osafoundation.org
Thu Mar 24 18:24:49 PST 2005

  Hi Maarten,

> - The listing of all the java namespaces, classes and methods in the
> PyLucene.i file has a few %rename statements. Were those necessary to
> prevent naming conflicts in Python or are they in place for esthetic
> reasons? (for example %rename(JavaOutputStream) OutputStream)

SWIG flattens the namespaces, as documented here:
There are two OutputStream classes wrapped in the PyLucene.i file:
One had to be renamed.

Other methods are renamed because they conflict with C++ or Python keywords.
'delete', 'or' are examples of this.

> - This same listing contains a lot of classes which you probably would not
> to call on directly from python/ruby. Am i wrong or is this needed for some
> special reason?

Which ones ?

> - Why are there c++ wrapperclasses in place for some java classes? Are those
> the classes called upon from python and need to increase or decrease there
> reference on construction and destruction of the instance of those objects?

I'm confused by your question. Which classes do you mean, for example ?

> - Concerning those wrapperclasses I would like to know why in the %typemap
> declarations some java classes are called from wrapperclasses if the normal
> call fails. For example: %typemap(in) jtokenfilter tries to convert a Python
> object to a java object with type TokenFilter. But why is there a catch
> block if this fails and why is this construction not to be found in other
> typemap declarations like %typemap(in) jchartokenizer which converts Python
> objects to java CharTokenizer?

The PythonTokenFilter class (and all other Python.... classes) are Java 
subclasses that implement native methods that call into corresponding python 
implementations. Instances of these classes wrap an actual python instance of 
a class providing the corresponding python implementations.
This is how 'extension' of a Java class is done in Python, via these 
Python.... proxy classes, in other words, SWIG in reverse.
The typemap(in) logic first tries to unwrap an already wrapped Java object. If 
that fails, then it means the object is actually a python object providing an 
implementation of the same set of methods.
See the PyLucene/cpp source tree for these proxy classes' implementations.

> - Why are there a lot of is(classname) and to(classname) methods implemented
> as extensions to some c++ classes? It looks like they are to be used as
> typecasters, but I can't really get their purpose.

When SWIG returns a java object to python it wraps it with an instance of
python class that contains the methods declared for that return type, 
exactly. So, if a method is declared to return 'Query' but it actually 
returns a subclass of Query such as 'BooleanQuery', the resulting python 
instance will only have methods corresponding to the methods on the Query 
class. The downcasting extensions allow that Java instance to be unwrapped 
and rewrapped as a subclass, such as BooleanQuery, in order to get access to 
the methods defined in that subclass.

> I hope the questions are clear and you are willing to answer them.

Some of your early questions are a little confusing. Could you be more 
specific ?

> Thanks in advance and with regards,

You're very welcome !


More information about the pylucene-dev mailing list