Eliminate initializers in favor of only callbacks

[ctrueden]

As proposed by @Stefan-Posch on imagej-devel, we may be able to get rid of the concept of module initialization completely, in favor of only callbacks. When a preprocessor populates a parameter value, its callback is called.

Potential obstacles:

• At the moment, callbacks only happen when the InputHarvester UI changes a value, not when Module#setInput is called. This is not necessarily intuitive though—we would change that in order to switch to only callbacks.
• If a parameter value needs to be derived from application state via service method calls, the callback would have to go on the relevant service(s). And in practice, those service values would never change beyond initially being set. But that wouldn't really hurt anything.
• If a "secondary" parameter value needs to be derived from multiple "primary" parameter values, each of those primary parameters would need a callback that includes a recalculation of the secondary parameter value. That is also fine, though.
• Chaining callbacks is not currently supported. That is, if a "tertiary" parameter is computed from a secondary parameter which is itself computed from a primary parameter, the primary parameter's callback would set the secondary parameter value directly, thus not triggering the secondary parameter's callback. It would be the programmer's responsibility to keep track of their "transitive parameter dependencies"—e.g., in the earlier example, the primary parameter's callback would need to update both the secondary and tertiary values.

[ctrueden]

If we do this, it would make #180 moot.

[adaerr]

It seems to me that initializers and callbacks can have very different jobs. I have a plugin for example whose initializer performs a rough but involved image analysis in order to initialize the parameter values to sensible guesses. The callbacks do none of this, suppose that the user knows what she is typing, and merely take care of updating an overlay. In the case at hand the initializer is a global one declared in @Plugin, but the point is that for the simple cases of non-dynamic Commands (regarding parameter types/numbers), the distinction between initializer and callback is quite usefull, and would have to be coded by hand if initializers were merged into callbacks.

Maybe I got something wrong about the proposal, I just react because it reminds be a bit of the implementation difference of previewable plugins between IJ1 and IJ2: IJ1 chose to avoid a separate preview() method in favor of overloading run(), but I like the finer IJ2 granularity much better because my plugin is not doing quite the same thing for a preview update as for the final run, and some superfluous dispatching code is avoided.

[ctrueden]

@adaerr Do you think it would be sufficient to keep the single global initializer, while getting rid of the parameter-specific initializers?

[adaerr]

@ctrueden Yes, that sounds good. The global initializer seems more general than parameter-specific initializers anyway (the latter can always be concatenated into one global initializer). From a callback programming point of view it seems interesting in my eyes to be able to suppose that all parameters have already been populated, and that is achieved just as well by a global initializer.