[ImageJ-devel] Progress on the Beanshell/macro front

[Johannes Schindelin]

Dear Wayne,

[re-Cc:ing the list, since I think that this issue is of broader 
interest.]

On Wed, 14 Sep 2011, Rasband, Wayne (NIH/NIMH) [E] wrote:

> On Sep 14, 2011, at 2:09 AM, Johannes Schindelin wrote:
> 
> > I now have a proof-of concept of the Macro interpreter based on 
> > Beanshell. Note: it only supports the getDimensions() function for 
> > now. As described earlier, the problem is that that function takes 
> > possibly uninitialized variables by reference rather than values, 
> > which is fully out of line with the syntax of Beanshell (or C or 
> > Java).
> > 
> > Instead of forking Beanshell, I decided it'd be better to use 
> > javassist to rewrite a few method calls here and there. I also wanted 
> > to make sure that these modifications do not affect Beanshell itself, 
> > and I put a particular focus on making it possible to load the 
> > Beanshell classes before doing the Javassist modifications (because it 
> > would lead to nasty side effects otherwise).
> 
> Why would you want to base the macro interpreter on Beanshell? This is 
> going to require a *lot* of work and the resulting Beanshell-based 
> language is unlikely to be 100% backward compatible. I thought the plan 
> for handling backward compatibility was to hand off legacy macros and 
> plugins to IJ1.

There are a lot of power users out there who need the macro language to 
exist also in IJ2. So we cannot simply drop it.

But the legacy macros will not handle IJ2 properly. So we need something 
better.

Also, the limitations of the Macro language are rather severe, not being 
able to interact with the Java API. Now is the time to break that barrier.

There is another rather big problem with the Macro language that I'd like 
to address at the same time: the functions of the macro language are not 
available to Java programmers. In many cases, one can work around that by 
adding chunks of Java code (but there is no consistent way how to 
translate calls to macro functions into Java code), but in some cases, it 
is plainly impossible to do the same thing in Java which is very easy in 
macros (because of the use of package-local methods and fields).

As I suggested at multiple occasions, a properly designed macro interface 
should have a 1:1 correspondence in the Java API. Because if you need to 
be able to do something using macros, there is no good reason to believe 
that the same functionality should be lacking from the Java-accessible 
API.

With the redesign, there will be finally a Java class that defines all the 
macro functions, so we have that 1:1 correspondence not only in the usage, 
but it will indeed be the very same code performing the actions, so there 
is no room for inconsistencies between macros and plugins.

Yes, it will be a lot of work, but I dare to hope that you will notify me 
whenever you change something in the macro language so that I can take 
care of the IJ2 version thereof.

Unfortunately, given the architecture of the IJ1 Macro interpreter, I do 
not see any chance to modify the IJ1 code such that it naturally 
transforms into the IJ2 Macro interpreter. If you do see such a chance, 
please enlighten me.

Ciao,
Johannes