Greetings,
Thank you for your answer!
Alessio Stalla alessiostalla@gmail.com writes:
This is great, thank you very much for taking the time to write these examples!
My pleasure, I'm glad you found them worthwhile. I was also surprised to see this post in Planet Lisp via Zach Beane's blog, which was cool :)
I think the current incarnation of JSS is mainly a layer above jcall etc. - BUT it can be more efficient than naive use of the native Java FFI because it knows how to cache reflection metaobjects (e.g. methods). I don't know the details, though.
I didn't even considered anything related to performance. For my purposes in terms of simple GUI programming I would not mind trading some performance for overall ease of use though... well, depending on the real difference in terms of user experience of course.
Having said that, it would be interesting to benchmark the different APIs.
Interesting. I had looked at JFLI ages ago, before I started using ABCL, but I don't know much about it.
Since it's Rich Hickey's work before Clojure it is interesting to compare, and since ABCL recently incorportated it I was intrigued by it.
But really, I think the class-name-followed-by-dot prefix is a design smell. I think that a Java class should be mapped to a Lisp package, and methods and fields to symbols in that package (perhaps inherited from another package following Java inheritance). Then, you would have the options to write
(java.lang.Comparable:compare-to x y) (Comparable:compare-to x y) ;Assuming a package nickname (compare-to x y) ;If you imported the symbol or used the whole package
You could also map Java access modifiers to symbol visibility:
public -> external protected -> internal, but explicitly imported in subpackages private, default -> internal (...)
That's not entirely unlike what JFLI does: I'm using (use-package "javax.swing") since JFLI maps Java packages to CL packages; what you are proposing is the mapping of Java *classes* to CL packages, which I agree would reduce the "clutter" somewhat, especially because it is IMO a bit strange to have to specificy the class of a method *and* provide the object that receives it.
JFLI seems to go to great lenghts to integrate itself into CL packages, etc. I'm still exploring it though. JSS OTOH "just works", it's simple to use and does what it is supposed to (JFLI requires a bit more setup).
ABCL could certainly benefit from more high-level macros. Right now we only have java:chain that allows you to chain method invocations, like some Clojure operator I don't remember (->> or something) and like a.b(x).c(y).d(z) in Java.
Didn't knew about java:chain, thank you - I'm still reading about the java interop facilities, my impression is that there is a lot under the hood that isn't known (and thus not used). I'm still going to add the "low level" example that uses jcall, jmethod, etc.
In the most simple scenario syntax differences are as follows:
ABCL JSS: (#"setText" my-label "The Larch") ABCL JFLI: (jlabel.settext my-label "The Larch") Clojure: (.setText my-label "The Larch") (...)
Yep. Personally I don't like it very much, because it's more stuff than a simple reader macro...
True. I think that the ability to simple use (settext my-label "The Larch") would be great, but I suspect that if this was simple it would already be done ;)
A bit OT, but not unlike another obvious idea, which would be to support CLIM using Java interop and Swing, thus making code targeted at ABCL universal in both ways: completely self-contained due to the JVM, and also able to be deployed in other CL implementations. This would IMO be something that would make the "CL hosted on the JVM" really shine.
This assumes that CLIM is actually 1) a standard and 2) a good approach to GUI programming, something that can be debated
You might want to look at the java.lisp file. It contains a bunch of interesting and not widely known operators. ABCL's FFI is really more than just invocation of methods; you can, among other things:
- implement interfaces with proxies
- specialize CLOS generic functions on Java classes
- use Java lists as sequences
- write Java classes in Lisp (this is work in progress)
There are also a couple of pages in the abcl wiki that I wrote or contributed to, but they're incomplete unfortunately.
Thank you, I will do that. As I mentioned preivously perhaps my (completely trivial) experimentation can help in uncovering hidden functionality with examples, etc. The CLOS specialisation seems extremely interesting BTW.
"Write Java classes in Lisp"... this is, I must confess, where I am stuck at the moment. I'm trying to make another, slightly more complex, example that involves a canvas-like interface. For this the examples I find (in Java) imply overriding the paintComponent method of JPanel. This is something that apparently can't be made by using interfaces, I need a new class (or proxy). I can't seem to find how to do this in ABCL - at least using JSS or JFLI. This is such a deal breaker that I am surely missing something obvious.
BTW, I've read some of your material in Snow, I haven't gone for that route yet since before using a framework I want to understand the gory details, but it's very helpful.
Thank you and best regards,
Frederico