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

[Alessio Stalla]

On Tue, Dec 22, 2009 at 9:05 PM, Tobias C. Rittweiler <tcr at freebits.de> wrote:
> Alessio Stalla writes:
>
>> On Mon, Nov 23, 2009 at 2:47 PM, Alessio Stalla wrote:
>>
>> Now jcall can be used with less verbose syntax, for example:
>> (jcall "toString" 4) ==> "4"
>> (jcall "compareTo" 4 5) ==> -1
>>
>> it would be nice to add (#"methodName" args) a la JSS for even shorter syntax.
>
> FWIW, I do not like the special read syntax. I think, the real solution
> that ABCL should strive for is
>
>  - to implement per-package symbol case sensitivity a la Clisp
>
>    See  http://clisp.cons.org/impnotes/package-case.html
>
>  - introduce a package JAVA (with nickname J) where symbols are
>    interned in while preserving case.
>
> Ultimatively, ABCL should strive for making
>
>  (funcall j:compareTo 4 5)  [read in as (FUNCALL J:|compareTo| 4 5)]
>
> work.

I assume you mean (funcall (quote j:compareTo) ...), and if we had
that, also simply (j:compareTo ...)

For that to work, we should alter the semantics of the language quite
dramatically, and I'm not even sure the result would be CL anymore.
E.g.

(let ((fn (symbol-function 'j:someMethod)))
  ...much later...
  (funcall fn some-obj))

should be possible, but in that case the unbound function (or method
not found) error can only be signaled at the time of the funcall,
since the existence of the method can only be determined given the
argument types. I don't think such dramatic changes would buy us
anything good.

If you want to pass around Java methods like they were closures, you
can simply wrap the call in a lambda and pass that. You could even
write a jlambda or something macro to create the closure for you.

Alessio