Come up with concise documentation about the naming strategies about imagej-ops

[ctrueden]

We had the naming discussion in Konstanz and I thought we agreed to the following:

• For each kind of operation, define a package and interface with that name. E.g.: imagej.ops.mean with interface Mean for operations named "mean". 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.).
• It is OK to have subinterfaces for different sorts of ops with the same name. See for example the type hierarchy of imagej.ops.join.Join.
• Then, for each Foo interface, create an AbstractFoo base class, as well as one or more concrete implementing subclasses each annotated with @Plugin. Again, see the type hierarchy of imagej.ops.join.Join for an example.

[ctrueden]

@dscho: Were there other aspects of naming that you feel are unclear or inconsistent?

[dscho]

@ctrueden that's a nice summary! I'll turn it into a document after addressing a couple of completely unrelated issues.

[ctrueden]

Thanks, @dscho.

[dietzc]

Sometimes the names are pretty long. Of course you can argument that in most of the cases you will not use the class names to instantiate those classes, rather one would use the name of the plugin, e.g. "join", anyway the long names are still somehow suboptimal.

Anyway, just for curiosity: What about things like putting an "I" in front of interface definitions and let the default definitions be the interface name without any "I"?

[ctrueden]

What about things like putting an "I" in front of interface definitions and let the default definitions be the interface name without any "I"?

We considered that when ImageJ2 first began 4 years ago, but:

1. The idea is for the names to be shorter, easier, more elegant, etc. for the API consumers. And on the flip side, it is OK for them to be a little more laborious for the API implementors. So the people using services should use a PluginService not an IPluginService. That's interface-driven design: the interfaces are the object references that get passed around everywhere. Calling the default plugin service simply PluginService encourages people too much to use that class directly, when actually they should (almost) never import or use that class directly.
2. If we changed the naming scheme like that, I would want to do it across the board for the whole SciJava software stack and IMO it is vastly too late for that.

So anyway, I really like our current naming strategy and have no issues with it!

[ctrueden]

There is the start of such a document about naming, BTW, at:
http://developer.imagej.net/coding-style#Naming

[ctrueden]

@dscho Just a quick ping that this issue is still open. I'll leave it in 0.2.0 for now (i.e., "high priority" milestone), unless you are too busy to tackle it before mid-November.

[ctrueden]

I started a document on the wiki. It is not fully specified, but it's a start. We will continue to update and flesh it out as needed.