On Monday, January 13, 2014 5:40:32 PM UTC-5, Avik Sengupta wrote: > > >(It might be possible to massage the difference using the Java > reflection to examine the method list and try to find one that fits a given > set of arguments, but that seems like it would be tricky to implement.) > Yes, that's the plan. Its a lot of tedious reflection methods, but I think > it should be possible. Given that the search is hierarchical (names, > cardinality, then types), it should be easy for the vast majority of > methods, but I'm not sure if every corner case of Java dispatch can be > handled. The problem comes down to: given a set n-tuple of Java types, > which of them best matches an n-tuple of Julia types. Maybe for the > pathological cases, we can just try all possibilities by turn. >
pyjnius uses a huristic function<https://github.com/kivy/pyjnius/blob/master/jnius/jnius_utils.pxi#L86-#L231>to figure out dispatch. I've only used it a couple of times but it worked pretty well when I tried it. I wonder how well it handles the corner cases you mention. On Monday, 13 January 2014 21:42:14 UTC, Steven G. Johnson wrote: >> >> >> >> On Wednesday, January 1, 2014 11:22:11 PM UTC-5, Eric Davies wrote: >> >>> Q1: Is there any reason why input types need to be specified, or could >>> an interface like PyCall's be implemented (where Julia types are converted >>> to their corresponding types and Python types are passed as they are)? >>> >> >> The situation is different in Java and Python, because the former is >> statically typed and the latter is dynamically typed. With Python, PyCall >> can just convert a Julia object into whatever the closest Python equivalent >> is, pass it to a Python function, and hope for the best. With Java, the >> JNI interface requires you to know the precise type signature of the method >> you want to call. >> >> (It might be possible to massage the difference using the Java reflection >> to examine the method list and try to find one that fits a given set of >> arguments, but that seems like it would be tricky to implement.) >> >
