Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature idea converters and adapters #800

Open
Thrameos opened this issue Jul 18, 2020 · 0 comments
Open

Feature idea converters and adapters #800

Thrameos opened this issue Jul 18, 2020 · 0 comments
Labels
enhancement Improvement in capability planned for future release
Milestone

Comments

@Thrameos
Copy link
Contributor

Thrameos commented Jul 18, 2020

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?

@Thrameos Thrameos added the enhancement Improvement in capability planned for future release label Jul 18, 2020
@Thrameos Thrameos added this to the JPype 2.0.0 milestone Jul 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement in capability planned for future release
Projects
None yet
Development

No branches or pull requests

1 participant