As you are possibly aware, we have not been able to move to versions
of Jython beyond 2.2 because an issue related to overloaded Java
methods that have signatures with identical numbers of parameters, but
one signature has a parameter that is a "Real" and the other has a
"double" for that parameter. In 2.2, preference was given to the Real
signature; in 2.5, however, since the Real class contains a __float__
method, Jython uses it to fetch the numeric value and then the calls
the method using the "double" signature.
While the Jython developers acknowledge this did, indeed, change after
version 2.2, they are not going to "fix" it. They have, instead,
suggested some ways for us to correct this -- mostly including a
dependency on the jython.jar file or using reflection....and at least
one of which caused an interesting stack overflow. Right now, neither
of these options seems tenable to me.
While I was thinking about this, it occurred to me that the _only_
issue is that the Real class contains numeric conversions (like
__float__) that Jython discovers and then gives preference to. No
other VisAD class contains these "get the value" methods...
What would be the ramifications if we removed these conversions from Real?
What purpose do they serve from the "user" (scientist, programmer)
stand point?
If we want people to get the value of a Real, we give them the
getValue() signature. Otherwise, they work with Real objects. What
is the downside to doing this?
I mean it's not like if you do something like:
m = Real(10)
k = 7 * m
you get a jython double for "k" -- no, you get a Real, since in
extending DataImpl contains the proper __add__ method, etc. I would
hope that people would be already using getValue() when they want the
numeric value.
The only downside I can see is if someone is passing a Real to a
function that requires a numeric value and they just let the __xxx__
methods do the fetching. We would have to teach them to use
getValue().
The upside is that if we do this, we can move on to version 2.5 and
beyond....Jon Beavers tells me there are distinct advantages to
that...
Comments? Other ideas?
--
Tom Whittaker
University of Wisconsin-Madison
Space Science & Engineering Center (SSEC)
Cooperative Institute for Meteorological Satellite Studies (CIMSS)
1225 W. Dayton Street
Madison, WI 53706 USA
ph: +1 608 262 2759
