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: http://www.swig.org/Doc1.3/SWIGPlus.html#SWIGPlus_nn31 There are two OutputStream classes wrapped in the PyLucene.i file: org.apache.lucene.store.OutputStream java.io.OutputStream 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 !
Andi.. _______________________________________________ pylucene-dev mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
