-
Notifications
You must be signed in to change notification settings - Fork 42
Naming
Each op has a name, which is not necessarily unique. This allows multiple "overloaded" ops with different combinations of parameter types, similar to the method overloading feature of Java and other programming languages.
Ops may optionally have a namespace. This is similar to packages in Java and similar features in other languages. The namespace is expressed as a prefix; such ops are referenced by their namespace, followed by a dot, followed by the op name. Ops without a namespace belong to the "global" namespace, with no prefix or dot. Two ops with the same name but different namespaces do not "overload" or "override" one other.
The naming convention for both namespaces and op names is to use a alphameric string, all lower case.
We use the following guidelines:
- For each kind of operation, define a package and interface with that name. E.g.:
net.imagej.ops.mean
with interfaceMeanOp
for operations namedmean
. Copy and paste an existing interface when doing this, so you keep the style identical (NAME
constant, javadoc blurb about how to annotate the@Plugin
, etc.). Or better, use a Velocity template and list file to autogenerate it; see e.g. Ops.list and Ops.vm for an example. - It is OK to have subinterfaces for different sorts of ops with the same name, if needed.
- For each
FooOp
interface, create anAbstractFooOp
base class, as well as one or more concrete implementing subclasses, each annotated with@Plugin
. If you have a single concrete implementing class, it will typically be namedDefaultFooOp
. See the type hierarchy of net.imagej.ops.identity for a simple example. - The reason for the
Op
suffix ofFooOp
etc. is in case the operation works with a data structure of the same name. For example, aMeanOp
might compute aMean
, aSmallestEnclosingRectangleOp
might compute aSmallestEnclosingRectangle
, and so on.