On Thu, Sep 23, 2010 at 10:00 PM, mahmud bigthingist@gmail.com wrote:
Hi there,
First, a big thank you and congratulation on a job well done, everyone!
Secondly. What is the community take on jfli[1] and jss[1]? I like them both, and I plan to use them heavily to Lispify a few Java libraries. However, the two are incompatible, they both have features I would like to see merged.
I don't know anyone here using jfli. Instead, I know a few people using jss, and Alan Ruttenberg, its author, posts here.
Have there been any attempts at wrapping the native FFI with something higher level? I am interested in something that does the following:
Yes, I contributed some patches to make the native FFI usable with less verbosity (but more runtime overhead) if one so wants. It's more or less a subset of what jss already did before, but without the more advanced features (reader macros, caching of method metaobjects, probably other stuff I don't remember). If there's interest, I can port other features - in any case, API compatibility with jss is a goal for me.
- Automatic importing of java packages and making them into Lisp packages.
I don't like this. Java packages aren't a well-defined entity at runtime: you can't portably enumerate their contents, and the set of classes in a package can vary with time (new classes get loaded) and with classloader (the set of directly accessible classes is determined by the current classloader).
What I would like is:
a) importing a single class name as a Lisp symbol, say (jimport-class "com.foo.whatever" 'foo:whatever), then you can do e.g. (jnew 'foo:whatever 1 2 3)
b) using an "import list" to resolve class names against (like javac does at compile time): (jimport-package "com.foo") (jimport-package "com.bar") (jcall "baz" (jnew "Foo")) and "Foo" is searched in com.foo and com.bar if not found.
- Succinct, case-indifferent syntax.
I don't like case-indifferent either. First it means you can have collisions, second that resolving a class is O(2^length(classname)) in the worst case.
I would like to extend either of them to do:
- Subclassing of java classes in Lisp.
this will be possible, thanks to the great work of Erik Huelsmann on a generic class file writer API. I'd like to work on it actually, but I'm too short of time these days :(
- Ability to implement java interfaces in Lisp classes.
This is already possible to a certain degree, see jmake-proxy. But you have to translate yourself between Java method names and Lisp generic function names, unless all your GFs are in the same package and they are named along the Java method names (someMethodName becomes SOME-METHOD-NAME). And of course, in any case only GFs that take the receiver (this) object as their first parameter work without wrappers.
I have a few more ideas, most of which are feasible, but would like to get the community's input on FFI wrappers before I head off in a solitary direction.
My own personal opinion: our FFI should be enhanced without the use of external wrapper libraries when possible. This requires of course that those "enhancements" are widely agreed upon by the community, that they don't require external dependencies, and that they don't make the low-level API perform worse.
Cheers, Alessio