[armedbear-devel] [PATCH] jcall(there are multiple matchingmethods)

[Alessio Stalla]

On Wed, Dec 23, 2009 at 8:52 AM, Tobias C. Rittweiler <tcr at 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