On Tue, 18 Feb 2003, [EMAIL PROTECTED] wrote: > Sounds like a great idea! > > I would volunteer to re-write the Jalopy > (http://jalopy.sourceforge.net/) integration package I put > together. I could also take a stab at a re-write for the > integration package for PMD (http://pmd.sourceforge.net/). > > Those Elisp->Java packages have an awful lot of code in common, > and it would be really nice to create a standard way to create > them - specially the bit about a standard way to integrate with > the BeanShell. > > I would like to suggest also a standard way for those packages > to present their output. A lot of them generate warnings or > errors that go very well in a "compilation" mode buffer. I > think this behavior can be abstracted as well.
Maybe the beanshell could be viewed as an application server. Let me work through my thoughts. Would it make sense that java code that is executed through the beanshell not have to "println(someElispString);" but instead, any java code that is to be executed by the beanshell and subsequently eval'd into elisp, return a "java datatypes transformable to elisp" set of objects, like hashmap, array, ... Then, the beanshell could offer a set of classes which take these particular return objects and transform them into println's of elisp strings to be eval'd by elisp. The only part that doesn't seem clear to me is how to have elisp not have to understand the java code, its structure and exact names as well as its exact syntax. I'm thinking, first an eieio interface to elisp be required to be implemented by the elisp code of the package. A mapping layer, maybe xml, or just elisp list, be used to wire elisp class/method names to java class/methods. Then, the elisp package integrates with a particular elisp interface and the java code integrates with a particular java interface and the elisp to java is the black box that none of the two sides of code knows about, taken care of by the beanshell's black box. This would also allow java requirements for some particular need of the JDEE to be given to a willing java coder and the elisp requirements given to a willing elisp coder and the two sides actually code in their respective VMs without having to hook the two, fairly incompatible VMs up during development. Of course, what I'm thinking is that a JDE user could integrate some jakarta package by working with Paul on the java interface needing to be implemented. Paul or another of the elisp studs, then codes up the elisp side of the house waiting for the java coder to finish his work. Then, elisp becomes a client and the java code becomes the middleware implementing interfaces the beanshell application server will be executing. -- Galen Boyer
