On Tue, Feb 2, 2010 at 6:14 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
2010/1/30 Blake McBride <blake@mcbride.name>:
Greetings, Enclosed are the completed Lisp and Java utilities designed to make Lisp / Java interaction easier. It also includes an example / tutorial program. If it is appropriate, I'd like to have these added as one of the ABCL examples in the distribution. Also, if it is advantageous, perhaps we can move the Lisp and Java utilities to be part of ABCL.
Looks good. I think the ABCL java class could benefit from a setter for the interpreter, and a getter, so that you could use it as a decorator. Wherever an instance of Interpreter is created, I think it's better to allow people to use that instance for other things Interpreter is capable of. I'd add the possibility to have per-ABCL-instance Interpreters, as well as the option of having a class instance.
The utils.lisp stuff looks like it could well be added to our java.lisp, probably slightly tweaking the function names to follow the normal java.lisp conventions.
Would you like to do such tweaks, or should I? :)
Alessio, this is your familiar playground, any comments on these utils?
The Java utils for what I can see are a subset of what is already there in AbclScriptEngine, with the difference that - iirc - the script engine automatically calls javaInstance() on the returned objects, so you don't have the possibility to access "raw" Lisp objects (e.g. calling a function that returns a Fixnum will return an Integer instead). The lisp utils could be handy, but I'd prefer to call jmethod, jclass and similar during macroexpansion and including the results in the expanded code; this way no method/class reflective lookup will be done at runtime. For maximum safety, it would be even better to fall back to calling jmethod in the expansion, and warn, if method resolution fails at compile time. Wrt. multiple Interpreter instances, it's not entirely true that you can only have one; you can use two different, unrelated classloaders to load two copies of ABCL. It's true that, in that case, interacting with them with code from yet another classloader (say, a manager thread), will be harder and slower, as you can only use reflection; but if you just want two or more independent ABCLs, that can be the way to go. hth, Alessio