[snip]
> The advantage of this approach is that it reduces developing
> interfaces to external Java processes to writing eieio classes.
> The interface developer doesn't have to write any Java code or
> interprocess communications.
This is a very interesting idea! It cuts directly to one of the things
that a plug-in archtecture should do: hide difficult details
from the tool writer (interprocess communication) through
code generation and code re-use.
> This doesn't really help the elisp illiterate plugin tool developer,
> but it would make it easy to create and maintain a plugin
> interface for the JDEE.
What about doing it in the other direction: creating eieio classes
from existing Java classes? The generated eieio classes could extend basic
classes designed for easy integration into the JDEE plug-in framework.
Generating Lisp from Java seems to be more appropriate in this particular
problem, since typically the Java code will already exist (in the form of a
library or tool that we want to add to JDEE).
To create a pure Lisp plug-in, the designer would just have to extend the
plug-in eieio classes directly.
This is nice, it seems that this discussion is making some progress in terms of
a viable plug-in framework design...
Regards,
Nascif
