[ImageJ-devel] built ins

[Curtis Rueden]

Hi Brian,

> Is there documentation anywhere on how to update the built-ins after
> updating the signature of an op??

Not yet. We can make a wiki page. The other thing missing is a top-level
"built-ins completeness test" to make sure that all built-ins are actually
present and being tested for. (Right now, each unit tests covers a specific
op name, but there is no test that verifies all op names are being tested.)

Due to limitations in generic type matching (as described at
https://github.com/imagej/imagej-ops/issues/19), we were not able to fully
automate generation of the built-in methods. So unfortunately they must be
added manually. But there is a significant unit testing infrastructure that
tries hard to verify everything matches.

Here's a quick rundown:

1A) If you add a new concrete op implementation for an existing op name,
then the existing built-in test method will pick it up.

1B) Or if the implementation corresponds to a new name foo, you can add the
completeness test by adding a new testFoo() method to the appropriate
namespace test class (e.g., MathNamespaceTest for math, LogicNamespaceTest
for logic, or GlobalNamespaceTest for methods in the OpService itself).

2) The unit test will notice that your new op does not have corresponding
built-in method signature(s), and spit out a detailed error message
suggesting the method bodies to be added. The method bodies are pretty
close to correct except for they are missing generic parameters. So you
must tweak the argument types by hand to make the generics match the fields
of the concrete op implementation.

3) Then just paste the method body into the appropriate namespace class
(e.g., MathNamespace for math, LogicNamespace for logic, or OpService and
DefaultOpService for global. Then the relevant completeness test should
pass again.

4) If multiple ops have clashing signatures, you can make a single built-in
method with an @OpMethod annotation the specifies multiple concrete op
classes in its "ops" attribute. Method parameters and return type must then
use the most common compatible superclass of all involved ops.

Let me know if any of that needs clarification; happy to elaborate further,
and point out specific examples as needed.

Regards,
Curtis

On Mon, Jun 29, 2015 at 9:21 AM, Brian Northan <bnorthan at gmail.com> wrote:

> Hi everyone
>
> Just noticed that built-ins were added recently.
>
> https://github.com/imagej/imagej-ops/pull/145
>
> Is there documentation anywhere on how to update the built-ins after
> updating the signature of an op??
>
> Mainly I'm wondering if there is any scripts or automated code generation
> steps to perform??
>
> If it is just a matter of updating the signatures manually I can figure
> out how to do that.  Just want to make I don't miss an automated step I
> should be running.
>
> Thanks
>
> Brian
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150629/fa09cd15/attachment.html>