Consider using parameterized SciJava Command plugins

[ctrueden]

Right now, all the examples implement ij.plugin.PlugIn, which is the ImageJ 1.x interface for plugins. If the examples instead used org.scijava.command.Command, you could gain the advantages of SciJava parameterized modules, including auto-conversion of parameter types. Here is a simple example ImageJ Command plugin.

With this approach, it would no longer be necessary to explicitly convert types. Instead, you annotate parameter fields (using @Parameter) of the type needed by the algorithm itself, and the framework takes care of converting/auto-filling parameters whenever objects exist whose types are convertible to those field types.

Even in cases where you need to explicitly invoke a conversion for some reason, you also gain the power to write @Parameter ConvertService convertService and then in your run method you can say things like Mat mat = convertService.convert(IJ.getImage(), Mat.class); without needing to explicitly instantiate converter plugins. This provides extensibility, so that other converter plugins can be created to perform the same conversions in special cases more efficiently, for example. Whereas if you use new ...(), then there cannot be extensibility—you are locking in the implementation to that specific concrete class forever.

[joheras]

Thanks, that seems really nice. I am still learning all the amazing features provided by SciJava. I will let you know when this is implemented.

2017-03-16 18:53 GMT+01:00 Curtis Rueden notifications@github.com:

Right now, all the examples implement ij.plugin.PlugIn, which is the ImageJ 1.x interface for plugins. If the examples instead used org.scijava.command.Command, you could gain the advantages of SciJava parameterized modules, including auto-conversion of parameter types. Here https://github.com/imagej/example-imagej-command/blob/400c932ec97303e573d62c6fe5c08e6940ed34fb/src/main/java/com/mycompany/imagej/GaussFiltering.java#L26-L52 is a simple example ImageJ Command plugin.

With this approach, it would no longer be necessary to explicitly convert types. Instead, you annotate parameter fields (using @Parameter) of the type needed by the algorithm itself, and the framework takes care of converting/auto-filling parameters whenever objects exist whose types are convertible to those field types.

Even in cases where you need to explicitly invoke a conversion for some reason, you also gain the power to write @Parameter ConvertService convertService and then in your run method you can say things like Mat mat = convertService.convert(IJ.getImage(), Mat.class); without needing to explicitly instantiate converter plugins. This provides extensibility, so that other converter plugins can be created to perform the same conversions in special cases more efficiently, for example. Whereas if you use new ...(), then there no extensibility ever—you are locking in the implementation to that specific concrete class forever.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/joheras/IJ-OpenCV/issues/5, or mute the thread https://github.com/notifications/unsubscribe-auth/AFMQG-MUP5WDFDZ1oeL8EP40kp1TQ52Oks5rmXcIgaJpZM4MfqVk .