On Wed, Dec 23, 2009 at 8:52 AM, Tobias C. Rittweiler tcr@freebits.de wrote:
Alessio Stalla writes:
Too many special cases and deviations from CL for my tastes.
-I- haven't spoken about deviations.
Not directly, but you have implied them with your proposal, in my opinion. Correct me if I'm wrong.
[*] We could require Java methods to be declared as well: (define-jmethod foo "com.xxx.Bar.baz"). It doesn't even require modifying anything in the language, just have define-jmethod be a macro expanding to defun. But we would lose all the convenience.
I'm not talking about replacing the JMETHOD etc primitives; I'm talking about leveraging the package system as a means of integration rather than using a reader macro.
I haven't talked about replacing JMETHOD & friends either; my point is just that by "leveraging the package system..." you obtain a new language which is not standard Common Lisp anymore. If you don't agree, prove how (apply 'j:foo args) => something is conformant to the CL standard when j:foo does not name a Lisp function.
The benefits are that it allows the user to customize integration in a fine-grained way, and it provides for smoother integration (and by that merit, is more "Lispy".)
It's more about integrating Lisp and Java packages. That's the real problem to tackle (and it, as far as I see, subsumes method lookup.)
To integrate Lisp and Java packages is a different thing, very loosely related to method lookup in my opinion. First, Lisp packages are namespaces: in Java a namespace is either a package or a class. Also Java is like Lisp-2, i.e. the same symbol can name both a field and a method. One naive way to integrate them would be to have one Lisp package per Java package, containing symbols naming Java classes, and one Lisp package per Java class, containing symbols for Java fields and methods. Another, probably more sensible approach could be to just have a Lisp package per Java package and devise some naming scheme so that the symbol foo.bar in package baz names the member bar in class foo in package bar. There are other possibilities as well, but in any case you can't make the Common Lisp reader act specially on symbols in a certain package. You'd need either to iterate over the whole Java classpath and create all the packages and symbols at once, or have the user explicitly declare them, e.g. (jimport "com.foo.Bar") could create a Lisp package com.foo if it doesn't exist yet and put a symbol Bar in it and symbols Bar.xxx for all the members of Bar. jmethod and friends would then recognize those symbols (for example looking for a property in their plist) and act accordingly. I'm not sure I'd want to use something like that, but it's just an extension, so I'm not against it in principle.
Alessio