On Sat, Aug 1, 2009 at 12:18 AM, Tobias C. Rittweilertcr@freebits.de wrote:
To incite some discussion about what steps are required to make it convenient to write Java from within CL. The result should probably be added to Trac.
Short term:
* make Java objects inspectable.
Working on that ;)
* make DESCRIBE be useful on Java objects. Should mention inheritance tree, public attributes, and methods.
* fix inconsistencies, for example JMETHOD takes class-name first, then method-name, but JSTATIC takes it the other way around.
Medium term:
* make JMethods be a subclass of FUNCALLABLE-INSTANCE, so they can be funcalled, passed to HOFs, stored into SYMBOL-FUNCTION etc.
Cool. I never thought about this, it's a great idea. We probably need a JMethod extends JavaObject class to make this easier.
* add reader-macros for convenience. For example, #J'class.method for (jmethod "class" "method").
This would be useful, but I also think we should provide some kind of alias system to avoid having to write the full Java class name every time.
I have some private code that allows me to do (jimport "java.lang.String" 'string) and later use 'string as a Java class designator with a bunch of ad-hoc functions. E.g. (new 'string "asfdsf"). However, it's built on my personal taste, which does not make it automatically suited for being the user-level interface between Lisp and Java.
Also having to provide the full list of argument types to select a method is tedious: we need the possibility to choose the method at runtime based on the number and type of arguments, while of course retaining jmethod for lower level stuff, as it's more optimized. Again, I have code for this, and there's invoke.lisp too, and probably other solutions floating out there.
* add iteration macro, HOFs, for Java Collections.
* Figure out how to get arglist information from Java methods.
* Documentation
* Useful PRINT-OBJECT methods for Java Objects. For example, Collection objects could be printed showing their content, e.g. #<JAVA-CLASS COLLECTION [a b c d e]>. Make sure to make it heed the printer variables properly, though.
Yeah, that's very important imho. #<JAVA-OBJECT java.lang.Long {12345}> looks much worse than e.g. #<jlong 42>. We could maybe also use the #J macro above, or another reader macro, to make at least java primitive types and Strings readable.
Long term:
* Add an extensible sequence protocol, and make Java Collection abide it.
I'm for it all the way.
* integrate Java's object hierarchy into the CLOS object hierarchy. I'm not a CLOS expert, but a few people come to mind who to ask.
I did something along the lines of this some months ago (it should already be in abcl, but it hasn't been publicized - and tested - much). Basically, calling CLASS-OF on java objects returns a CLOS metaclass which describes the Java class hierarchy, and it is possible to have CLOS methods dispatch following that hierarchy, using the nonstandard (jclass "class") method specializer. This is very incomplete - general CLOS does not work on these metaclasses (e.g. no make-instance to create new objects, no introspection, etc.) but can be a starting point.
- Make it possible to extend Java classes from Lisp.
what about runtime-class?
- Make it possible to implement Java interfaces from Lisp.
This is already possible, although it probably needs a higher-level api (i.e. one or more macros allowing one to implement interfaces declaratively).
People who have experience with Clojure, and other Lisp-like languages on the JVM are welcomed to chime in how other do the integration, and how they like it.
Also people who have opinions how they'd like it to look like.
-T.
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel