Add NameService and NameProvider

[imagejan]

This allows to define a way to derive names from objects of third party libraries, e.g. for use in ObjectService, where objects are registered with a name and can be provided e.g. in a drop-down choice in the UI.

This pull request, together with imagej/imagej-legacy#263, will resolve this forum discussion about being able to automatically populate ij.measure.ResultsTable inputs, provided we implement the following ResultsTableNameProvider in a follow-up pull request to imagej-legacy:

package net.imagej.legacy.plugin;

import org.scijava.names.NameProvider;
import org.scijava.plugin.AbstractHandlerPlugin;
import org.scijava.plugin.Plugin;

import ij.measure.ResultsTable;

@Plugin(type=NameProvider.class)
public class ResultsTableNameProvider extends AbstractHandlerPlugin<Object> implements NameProvider {

	@Override
	public String getName(Object thing) {
		return ((ResultsTable) thing).getTitle();
	}

	@Override
	public boolean supports(Object thing) {
		return ResultsTable.class.isAssignableFrom(thing.getClass());
	}
}

(Suggestions welcome to make this even more concise!)

[NicoKiaru]

Hi @imagejan ,

Could this provide a mechanism to solve imagej/imagej-legacy#243 as well ?

[imagejan]

@NicoKiaru absolutely, it could solve the problem of having Pet@57a3e26a instead of Felix as a name in your example. In general, this allows giving names to any object of a third-party library (i.e. not under your control) by adding a NameProvider plugin that can be discovered at runtime.

[NicoKiaru]

Then it could be adde in the ij1 macro engine I guess ?

https://github.com/imagej/imagej-legacy/blob/5c46549e765b3148d767a8c90d15b6be03b4c154/src/main/java/net/imagej/legacy/plugin/IJ1MacroEngine.java#L251

[imagejan]

@NicoKiaru iff the change proposed here gets merged and included in a release, and then the change from v.toString() to objectService.getName(v) you proposed in https://github.com/imagej/imagej-legacy/pull/243/files#diff-de04251535e202b6132a0485276551de8ec4b1e86a639a9b54c67d63527ef5e1R251 is indeed sufficient to have the desired recording behavior (for objects where you also implement a NameProvider).

The remaining issue would then be the other direction, determining the object from the given name, which is potentially ambiguous, but let's discuss this on the imagej-legacy issue.

[NicoKiaru]

The remaining issue would then be the other direction, determining the object from the given name, which is potentially ambiguous

Getting a converter from String to an object can be handled quite correctly by converter I find, but ok, let's keep this as a discussion in imagej-legacy.

For this PR, I have a question regarding the following use case:

Imagine you have 5 different objects in the object service of a certain class Image. Would the mechanism you suggest assign a name to an array of such objects ? This could be convenient for an Image[] input parameter for instance.

If yes, could we make this modular ? Like can Object in your example, be of class Image[] ?