Wrappers do not intelligently select a method where there are several possibilities with the same number of parameters.

[sdh4]

I am trying to use this as a link to COMSOL. Unfortunately there are some methods ('set', most notably) with multiple overloaded methods that have the same number of parameters, but different types.

Right now, javabridge finds the first method with a matching number of parameters. It probably wouldn't be too difficult to search for an exact type match first.

It is possible to work around the problem by dropping down to the low-level interface and selecting the method manually, but this is rather complicated.

Thoughts?

[LeeKamentsky]

I can appreciate - the code to disambiguate could be improved and with some effort, it could follow the exact rules that Java uses or it could use some additional introspection to do so, such as java.lang.Class.getDeclaredMethod.

If someone wants to supply a patch, that would be nice.

[sdh4]

java.lang.Class.getDeclaredMethod is an intriguing possibility....

I had been thinking about just constructing a signature based on the Python parameters and then comparing that signature with the signatures of each of the available methods. Then picking any exact match or falling through to the current logic if that fails.

Any thoughts on the merits of the two approaches?

[LeeKamentsky]

Nothing is going to be perfect - there's just not a clear mapping of Python numerics to Java, although if you've got wrapped objects, it's easier. I think your approach of seeing if you can cast your parameters to the signature of each method will yield an unambiguous match in most cases which is better than what we have. Another approach may be to provide two Python methods per Java using something like C++ name mangling: https://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_C.2B.2B.

My go-to has always been to code at the lower level when I run into these ambiguities.

[sdh4]

Here's a possible approach: Have Python integers match either Java int or long. Have Python floats match either Java float or double. Have Python strings only match java.lang.String.

In the unusual cases when better specificity is required, the user can wrap the Python object with a 0-d Numpy array (or, in the case of an array object, a 1-d Numpy array), where the dtype is specified with a metadata dictionary entry javabridge_type or javabridge_class indicating the intended type.

For an example of the use of metadata in numpy dtypes see special_dtype() in https://github.com/h5py/h5py/blob/master/h5py/h5t.pyx