Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eliminate initializers in favor of only callbacks #181

Open
ctrueden opened this issue Aug 22, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@ctrueden
Copy link
Member

commented Aug 22, 2015

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 ctrueden added this to the 3.0.0 milestone Aug 22, 2015

@ctrueden

This comment has been minimized.

Copy link
Member Author

commented Aug 22, 2015

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

@adaerr

This comment has been minimized.

Copy link

commented Aug 29, 2015

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

This comment has been minimized.

Copy link
Member Author

commented Aug 31, 2015

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

@adaerr

This comment has been minimized.

Copy link

commented Sep 2, 2015

@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.

@ctrueden ctrueden added the parameters label Apr 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.