You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
type(jvals) = <java class 'java.lang.Object[]'>
type(jvals[0]) = <java class 'java.lang.Long'>
jvals = [8, 5, 3, 2, 1]
A similar JImplements proxy could be made for all of the various functional interfaces that are part of the Java standard library (Supplier, BiFunction, Consumer, BiConsumer, etc.).
Then, each Python function (or Callable more generally perhaps) could be wrapped to the an appropriate interface by examining its signature. But just because we could do that, doesn't mean we should... I don't have a good use case for automagical inference in this way, and it might not end up being doable—e.g. the only way I know of to glean whether a Python function returns anything is via type hints, which might not be present.
I think we should wait to think about this any further for the moment... I foresee returning to this issue as the SciJava Ops project gets further along and we start wanting to write existing Python functions as ops...
It would be nice to support something like this:
Where
FunctionFromPython
is:Then anything operating on a Java
Function
can accept a Pythonfunction
with appropriate conversion. For example:Prints:
😎
The text was updated successfully, but these errors were encountered: