@gselzer is this something that needs to be merged before @ctrueden comes back?

@hinerm no, it is not urgent. I only pinged you to:

• Ensure this PR is not forgotten about
• Get a (third) opinion on the syntax for method Ops. As someone who is not particularly in the loop about scijava-ops, do you think this syntax could be improved?

@gselzer for me, this seems unfortunately long:
@OpDependency(name = "stats.sum") Function<Iterable<Number>, Double> sumOp

If there was a way to do something like

@OpMethod(names = "stats.mean", type = java.util.function.Function.class, dependencies = {"stats.sum", "stats.size"})
public Double meanOp(

I think I might find that more pleasant, although I assume there's not a nice way to inject the parameters then.

Side note: what are the advantages of @OpMethod versus just taking OpEnvironment as a parameter, or giving all Ops implicit access to their environment? e.g. something like:

@OpMethod(names = "stats.mean", type = java.util.function.Function.class)
public Double meanOp(Iterable<Number> data) 
  {
    Double sum = ops().op("stats.sum").input(data).outType(Double.class).apply();
    Double size =  ops().op("stats.size").input(data).outType(Double.class).apply();
    return sum / size;
  }

Another side note: am I correct that in OpBuilder the op name doesn't actually get used until apply is called? If so it might be nice if the API allowed reusing the input and/or output configuration for multiple ops. Something like:

OpConfig conf = ops.op().input(data).outType(double.class);
Double sum = conf.apply("stats.sum");
Double size = conf.apply("stats.size");

Thanks for the feedback @hinerm. I will try to address each of your points:

If there was a way to do something like

@OpMethod(names = "stats.mean", type = java.util.function.Function.class, dependencies = {"stats.sum", "stats.size"})
public Double meanOp(

I agree that it is long, but it is also specific. We obviously cannot get shorter than Function<Iterable<Number>, Double> sumOp since that is the type and name of the parameter. This is already pretty long.

Furthermore, we need to be able to determine whether a given parameter is an Op. We cannot assume to know that if a parameter is of type X, Y, or Z then it must be an OpDependency; this would not be extensible. This is compounded by the fact that many ops (such as the project Op ) take functions as parameters that are not OpDependencies. This behavior should be available for method-based Ops as well.

If you agree with what I said above (and I would be thrilled if you found a way around this), we must also include the @OpDependency annotation to those parameters, which will also require recording the name.

Side note: what are the advantages of @OpMethod versus just taking OpEnvironment as a parameter, or giving all Ops implicit access to their environment?

The main benefit is that it provides independence from scijava-ops. If we wrote something along the lines of what you wrote above, we would then require anyone wanting to use our OpMethod to also require scijava-ops. @ctrueden has long been aware of people who do not want to go through the matching system, and this will allow them to do it. Of course, this requires them to find (write) their own sum and size ops in our example, so it is not particularly convenient to call them without Ops, but at least it can be done.

Another side note: am I correct that in OpBuilder the op name doesn't actually get used until apply is called? If so it might be nice if the API allowed reusing the input and/or output configuration for multiple ops.

You are correct in that the op name is not used until apply/compute/function/computer/... is called. I agree that the construction is nice, however I would not want to use it for anything other than Functions; Computers would not make sense under this construction since you would be overwriting the output again, and Inplaces could get really confusing really fast because you would have to keep track of which inputs were modified at which point. I am not sure how we would implement this for only Functions, thus I am hesitant to implement something along these lines. It might be worth further discussion, though...