[ImageJ-devel] Design meeting notes

[Johannes Schindelin]

Hi,

On Wed, 13 Oct 2010, Lee Kamentsky wrote:

>  On 10/12/2010 10:50 PM, Johannes Schindelin wrote:
>
> > On Tue, 12 Oct 2010, Curtis Rueden wrote:
> >
> > > > That was my first idea. But how would the user interface tell the 
> > > > callback without String or java.lang.reflect.Field ugliness which 
> > > > input was modified by the user (and by that, what field should be 
> > > > changed accordingly), and how would the callback tell that it 
> > > > changed something, and what?
> > > Each parameter has its own callback method, invoked when that 
> > > particular parameter changes. So as Lee said, which method is called 
> > > indicates which parameter was changed. (Perhaps it would be better 
> > > to call the attribute something like "onChange" instead.)
> > >
> > > Does that clarify it? Or is there a problem I'm not seeing?
> > Just the infinite recursion thing (which is harder than meets the eye; 
> > you'd have to build a graph and detect circles).
> >
> > It's also not clear how the callback would signal to the dialog (be 
> > that an ImageJ, or a KNIME or CellProfiler dialog) _what_ value was 
> > changed by the callback. (Just think of the user changing the width, 
> > and the callback wanting to modify the height _iff_ "keep 
> > aspect-ratio" is checked.)
> >
> The obvious unique ID (signaling what changed) would be the field's name 
> - I have enough Java reflection tools in CellProfiler at this point to 
> be able to pick out the field name and include it in an event.

The problem I have with this solution: it does not catch problems at 
compile time, but at runtime.

Ciao,
Johannes