>> "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
