|
29 | 29 |
|
30 | 30 | package org.scijava.ops.tutorial; |
31 | 31 |
|
| 32 | +import org.scijava.ops.api.OpEnvironment; |
| 33 | + |
32 | 34 | import java.lang.reflect.Field; |
33 | 35 | import java.lang.reflect.Method; |
34 | 36 | import java.util.function.BiFunction; |
35 | 37 |
|
36 | | -import org.scijava.ops.api.OpEnvironment; |
37 | | -import org.scijava.ops.spi.OpCollection; |
38 | | -import org.scijava.ops.spi.OpField; |
39 | | -import org.scijava.ops.spi.OpMethod; |
40 | | - |
41 | 38 | /** |
42 | | - * {@link OpCollection}s, as the name suggests, define many Ops within one |
43 | | - * class. |
44 | | - * <p> |
45 | | - * There are two different types of Ops that can be written inside |
46 | | - * {@link OpCollection}s: |
47 | | - * <ol> |
48 | | - * <li>{@link OpField}s are Ops written as {@code public final} |
49 | | - * {@link Field}s.</li> |
50 | | - * <li>{@link OpMethod}s are Ops written as {@code public static} |
51 | | - * {@link Method}s.</li> |
52 | | - * </ol> |
53 | | - * Each {@link OpCollection} can contain an arbitrary number of either type of |
54 | | - * Op. |
| 39 | + * While {@link OpTypes} shows how to write an Op as a {@link Class}, it is much |
| 40 | + * more convenient to write Ops with less code. This tutorial shows how you can |
| 41 | + * write Ops contained within {@link Field}s and {@link Method}s, leading to |
| 42 | + * less boilerplate code! |
| 43 | + * |
| 44 | + * @author Gabriel Selzer |
| 45 | + * @author Mark Hiner |
| 46 | + * @see OpTypes for information about writing Ops as {@link Class}es. |
55 | 47 | */ |
56 | | -public class WritingOpCollections implements OpCollection { |
| 48 | +public class WritingConciseOps { |
57 | 49 |
|
58 | 50 | /** |
59 | | - * {@link OpField}s are Ops written as {@link Field}s. They <b>must</b> be: |
| 51 | + * One major benefit of Ops written as {@link Field}s is that they can use |
| 52 | + * Java's lambda syntax, maximizing expressiveness. Field Ops <b>must</b> be |
| 53 | + * {@code public} <b>and</b> {@code final}, and should define Op parameters |
| 54 | + * using the following tags: |
60 | 55 | * <ul> |
61 | | - * <li>public</li> |
62 | | - * <li>final</li> |
| 56 | + * <li>{@code @input <name> <description>}</li> to describe a parameter named |
| 57 | + * {@code <name>} with purpose {@code <description>} |
| 58 | + * <li>{@code @container <name> <description>}</li> to describe a preallocated |
| 59 | + * output <b>container</b> parameter named {@code <name>} with purpose |
| 60 | + * {@code <description>} |
| 61 | + * <li>{@code @mutable <name> <description>}</li> to describe a <b>mutable</b> |
| 62 | + * input parameter named {@code <name>} with purpose {@code <description>} |
| 63 | + * <li>{@code @output <description}</li> to describe a lambda return with |
| 64 | + * purpose {@code <description>} |
63 | 65 | * </ul> |
64 | | - * One major benefit of {@link OpField}s is that they can use Java's lambda |
65 | | - * syntax, maximizing expressiveness. |
| 66 | + * |
| 67 | + * @input b the base |
| 68 | + * @input e the exponent |
| 69 | + * @output the result |
| 70 | + * @implNote op names="test.opField.power" |
66 | 71 | */ |
67 | | - @OpField(names = "test.opField.power") |
68 | 72 | public final BiFunction<Double, Double, Double> opFieldPower = (b, e) -> Math |
69 | 73 | .pow(b, e); |
70 | 74 |
|
71 | 75 | /** |
72 | | - * {@link OpMethod}s are Ops written as {@link Method}s. They <b>must</b> be: |
| 76 | + * Ops can additionally be written as {@link Method}s. Method Ops must be |
| 77 | + * {@code public} <b>and</b> {@code static}, and should declare their |
| 78 | + * parameters using the following tags: |
73 | 79 | * <ul> |
74 | | - * <li>public</li> |
75 | | - * <li>static</li> |
| 80 | + * <li>{@code @param <name> <description>}</li> to describe a parameter named |
| 81 | + * {@code <name>} with purpose {@code <description>} |
| 82 | + * <li>{@code @param <name> <description> (container)}</li> to describe a |
| 83 | + * preallocated output <b>container</b> parameter named {@code <name>} with |
| 84 | + * purpose {@code <description>} |
| 85 | + * <li>{@code @param <name> <description> (mutable)}</li> to describe a |
| 86 | + * <b>mutable</b> input parameter named {@code <name>} with purpose |
| 87 | + * {@code <description>} |
| 88 | + * <li>{@code @return <description}</li> to describe a method return with |
| 89 | + * purpose {@code <description>} |
76 | 90 | * </ul> |
77 | | - * <p> |
78 | | - * <b>In addition, Ops written as methods must specify their Op type.</b> This |
79 | | - * tells SciJava Ops whether this function should become a Computer, an |
80 | | - * Inplace, or something else entirely. |
| 91 | + * |
| 92 | + * @param b the base |
| 93 | + * @param e the exponent |
| 94 | + * @return the result |
| 95 | + * @implNote op names="test.opMethod.power" |
81 | 96 | */ |
82 | | - @OpMethod(names = "test.opMethod.power", type = BiFunction.class) |
83 | 97 | public static Double opMethodPower(Double b, Double e) { |
84 | 98 | return Math.pow(b, e); |
85 | 99 | } |
|
0 commit comments