Bug 689 - ResourceReader class can not be extended
Summary: ResourceReader class can not be extended
Status: CONFIRMED
Alias: None
Product: libsigrok
Classification: Unclassified
Component: Bindings: Java (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-01 16:50 CET by Marcus Comstedt
Modified: 2015-11-01 19:05 CET (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Comstedt 2015-11-01 16:50:54 CET
Because ResourceReader is a class with no constructors, it can not be extended.

Thus, it is impossible to create a custom ResourceReader to feed to the set_resource_reader() method of org.sigrok.core.classes.Context.

There should probably be an interface org.sigrok.core.interfaces.ResourceReader and a suitable overload of set_resource_reader(), like it works for log and datafeed callbacks.
Comment 1 Daniel Elstner 2015-11-01 16:53:13 CET
ResourceReader has a constructor.

But yeah, the class wasn't written with the intent to be bindable from Python or Java, although it could probably be made so if absolutely necessary.
Comment 2 Marcus Comstedt 2015-11-01 16:55:12 CET
I mean that the Java class does not have a constructor.

This needs to work for pure Java apps on Android to be usable.
Comment 3 Daniel Elstner 2015-11-01 17:21:49 CET
Anything else you need? Right now ResourceReader is not even reference-counted.
Comment 4 Marcus Comstedt 2015-11-01 17:28:16 CET
Hm, yes, there should be a way to hand over ownership to the Context like there is for LogCallbacks and DatafeedCallbacks.
Comment 5 Daniel Elstner 2015-11-01 17:31:29 CET
And it will be necessary to wrap struct sr_resource, and deal with the in/out parameter somehow.
Comment 6 Martin Ling 2015-11-01 19:05:10 CET
There is a SWIG feature called "directors" that allows you to subclass C++ classes in Java or other target languages. Basically, SWIG creates a class that wraps all virtual methods with its own hooks, and then calls into the target language class for those methods.

I've not looked in detail but it sounds like that may be what's needed here.