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
While discussing how to build bindings for a large Java library, I came up with a way we can improve our current wrapping system.
Since we are now forcing convertToString to be False (or at least strongly encouraging it) we need to give better fine grain controls. ConvertToString was globally bad because if someone wanted to have strings converted for one class they would force that decision on all classes even other libraries that were included. Therefore, making the global behavior potentially break other pieces of code. Hence something deserving of deprecation.
But the concept of converting resources is not entirely bad. If you have an API which returns a lot of short strings where the conversion cost is low anyway and the end user is never going to want to have access to the Java string then it makes sense to do the conversion for that case. More generally suppose that you have an API returning large images and you want to automatically expose them as numpy arrays backed by raw memory rather than forcing the user to deal with a Java buffer type. You can achieve this by writing a customizer that wraps each class method and changes the return type, but that would be a pain especially if the user changes the API and now you have to maintain all those method calls.
So lets try to give the user a fine grain control at the wrapper level.
Proposal: use keyword arguments to allow customizers to define what goes into a class and what comes out.
@JImplementationFor(MyClass, adapters=AdapterMap, converters=ConvertersMap)
class MyClassImpl:
pass
Here we are defining the behavior for the Java class MyClass. We are providing a local list of adapters (which we will need to work out syntax as we need to be able to key on JavaType => protocol => Conversion function maybe {JavaType:{protocol:func, protocol:func}), and a converter map {JavaType:ConversionFunction}. When the class is created it will pass these keywords to each of the class methods and thus allowing those methods to use the adapters and converters whenever they are called.
This will allow us to do things like achieve convertStrings for one class by giving converters={String:str} which will call str on any Java Strings produced. We can potentially make even finer grain controls by adding annotation on individual method stubs so that we can pass keywords to individual method dispatches as they are created.
It will be a bit of work to achieve this, but it seems doable in the current framework. Anyone think this is worth adding to Jpype?
The text was updated successfully, but these errors were encountered:
While discussing how to build bindings for a large Java library, I came up with a way we can improve our current wrapping system.
Since we are now forcing convertToString to be False (or at least strongly encouraging it) we need to give better fine grain controls. ConvertToString was globally bad because if someone wanted to have strings converted for one class they would force that decision on all classes even other libraries that were included. Therefore, making the global behavior potentially break other pieces of code. Hence something deserving of deprecation.
But the concept of converting resources is not entirely bad. If you have an API which returns a lot of short strings where the conversion cost is low anyway and the end user is never going to want to have access to the Java string then it makes sense to do the conversion for that case. More generally suppose that you have an API returning large images and you want to automatically expose them as numpy arrays backed by raw memory rather than forcing the user to deal with a Java buffer type. You can achieve this by writing a customizer that wraps each class method and changes the return type, but that would be a pain especially if the user changes the API and now you have to maintain all those method calls.
So lets try to give the user a fine grain control at the wrapper level.
Proposal: use keyword arguments to allow customizers to define what goes into a class and what comes out.
Here we are defining the behavior for the Java class MyClass. We are providing a local list of adapters (which we will need to work out syntax as we need to be able to key on JavaType => protocol => Conversion function maybe {JavaType:{protocol:func, protocol:func}), and a converter map {JavaType:ConversionFunction}. When the class is created it will pass these keywords to each of the class methods and thus allowing those methods to use the adapters and converters whenever they are called.
This will allow us to do things like achieve convertStrings for one class by giving
converters={String:str}
which will call str on any Java Strings produced. We can potentially make even finer grain controls by adding annotation on individual method stubs so that we can pass keywords to individual method dispatches as they are created.It will be a bit of work to achieve this, but it seems doable in the current framework. Anyone think this is worth adding to Jpype?
The text was updated successfully, but these errors were encountered: