> > How about opening your script with:
> > __javawrapper__ =3D yourWrappingClass
> > ?
> > yourWrappingClass is a python class that would be automatically
> > instantiated as a wrapper for every java object created.
> > A java flagging interface would not even needed.
> I think a flagging interface is needed, because the majority of java
> classes won't be part of this game. The interface is needed on the java
> side to keep track of these special classes, and in Jython for knowing
> where to enable the Special Methods. This is independent of the
> implementation: Even your __javawrapper__ would have to decide if it
> wants to wrap or not, or, as you say below, the code deciding to
> instantiate/not instantiate the wrapper:
> > In case __javawrapper__ is not instantiated, the java wrapping
> > behaviour would default to the current behaviour.
> > In principle, this also allows to remove the current behaviour
> > from java and
> > move it into eg. a built in __defaultjavawrapper__.
It's probably better to define this wrapper as a function (much like=20
Py.java2py is a static method) than as a class, as I suggested above.
> Coming from the java side, I'd rather not replace java code by python
> code, more likely the other way round :-) (reading your next mail)
> As you and Brian pointed out, it could be solved using a pluggable
> python wrapper class. I personally would prefer an implementation
> completely in java. Maybe we could do both <smile> ?
> Now I am a little confused about what the *right* way is.
Since these special methods are defined for use _in_ the python language,
I think that is where they should be used.
Now, how is calling the special methods implemented for Python objects, i=
instantiations of the java class PyObject ?
I don't know enough of this to compare it with the scheme sketched below,
so it might be incompatible with the current situation. If this scheme ma=
little sense, please tell me.
As I suggested above, a python wrapper (A) around java objects could be u=
to redirect the calls to java. (A) would be returned by __javawrapper__.
The current implementation of jython also defines a proxy object (B) for =
java object (C) accessible from python.
I think we should find a good distribution of responsibilities between th=
python wrapper (A) and this proxy object (B)
The python wrapper (A) would take care of handling the special methods a=
redirecting them however it wants to the wrapped java objects, via (B).
The proxy object (B) would then be responsible for mapping the python typ=
to and from the java types and performing java method lookup and java=20
attribute lookup. I tried finding the source code for such proxies but I =
found PyProxy.java and PyReflectedFunction.java.
Currently CollectionProxy's have the role of (A) as they redirect python=20
special methods to Collection objects. However, they are implemented in j=