Eric == Eric M Ludlam [EMAIL PROTECTED] writes:
Nick Sieger [EMAIL PROTECTED] seems to think that:
PK == Paul Kinnucan [EMAIL PROTECTED] writes:
PK Eric M. Ludlam writes:
Something I always wanted to do was use EIEIO to wrap Java
objects. EIEIO could act as a proxy for Java objects, and there
could be Java object proxies for EIEIO objects. In this world
people who know Emacs could hack Java, and vice-versa w/out
having to know the other language much.
PK I've suggested to Nick Sieger that he use eieio proxies for the
PK Lisp counterparts that JUCI generates for Java classes.
I'm very interested in doing this, and as soon as I find time to
learn enough about EIEIO to feel comfortable I'll do this. But for
now, a Java method call is mapped to a plain-old-defun :-|
Eric [ ... ]
Eric I can help you do this. I don't have a working JDEE install at
Eric home though. I can help you create new classes and methods at
Eric runtime instead of in code. The secret is that if you want to
Eric use `defclass' or `defmethod', but don't want to write out code,
Eric you can use `eieio-defclass' and `eieio-defmethod' instead.
Eric Let me know what data you have and what you would ideologically
Eric like, and I can try to prototype it for you to get you started.
Of course. Making runtime, dynamic proxies, I wouldn't have thought
of that, but it makes good sense.
On the Java side, an interface needs to be declared that we'd bind to.
There also needs to be a provided implementation of that interface to
actually invoke, but the schema of the object if you will should be
in a Java interface (or interface inheritance hierarchy).
The more I think about it, maybe this isn't as hard as I initially
thought. The basic idea is to create an EIEIO class for each
interface, starting with a provided interface, and traversing up the
interface's inheritance hierarchy. Does EIEIO support multiple
inheritance? Ideally it would, since Java interfaces can extend
multiple superinterfaces. A recipe for a prototype might do something
like this:
1. Call `jde-complete-get-classinfo' with the name of the Java
interface we're proxying. Currently, this returns a data structure
like the following:
(jde-complete-get-classinfo jde.juci.test.Echo)
==
((ack(java.lang.String) : java.lang.String . ack())
(roundTrip(java.lang.Object) : java.lang.Object . roundTrip()))
where jde.juci.test.Echo looks like this:
public interface Echo {
String ack(String message);
Object roundTrip(Object input);
}
Unfortunately, `jde-complete-get-classinfo' only returns method
information, not superclass/superinterface info. Is there another
JDE method that would provide the methods of a class but also the
supers (anyone)?
2. Create the EIEIO class to be structured something like this
(assuming the implementation of the Echo interface is
`jde.juci.test.EchoImpl'):
(defclass jde-juci-test-echo ()
()
EIEIO proxy for jde.juci.test.Echo)
(defmethod jde-juci-test-echo-ack ((this jde-juci-test-echo) message)
Proxy method for jde.juci.test.Echo.ack(String)
(jde-juci-invoke-java jde.juci.test.EchoImpl ack message))
(defmethod jde-juci-test-echo-round-trip ((this jde-juci-test-echo) input)
Proxy method for jde.juci.test.Echo.ack(String)
(jde-juci-invoke-java jde.juci.test.EchoImpl ack input))
Now, the fun part is figuring out what to do with the proxies. Does
this seem reasonable so far? Anything I left out or that you would do
differently?
The next logical step would seem to be to make JDEE plugins simple
java classes, that possibly implement a pre-defined interface. On the
Elisp side, these would be EIEIO proxies that extend a base class that
would provide the plugin infrastructure (registration in a menu,
documentation, etc.).
/Nick
