On Fri, Jan 29, 2010 at 4:16 PM, Alessio Stalla alessiostalla@gmail.com wrote:

On Fri, Jan 29, 2010 at 10:07 PM, Erik Huelsmann ehuels@gmail.com wrote:

...

Hi Alan,

On Fri, Jan 1, 2010 at 9:37 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:

...

Can it be made so that within jcall, t or nil is understood as a java boolean argument?

Thanks for the idea. I've filed a ticket for it in order to prevent it from getting lost.

Ok for T, but NIL currently means null and I'd like it to stay that way. We could treat it as false for boolean arguments only, but:

• what to do with java.lang.Boolean? null or false?
• method resolution becomes more complicated: does (jcall "foo" nil)

select foo(boolean) or foo(Object)?

I don't think it can work to have it be both. If nil isn't false, then can we have a constant that is? Personally, I'd have nil be false and java:null be null pointer, but I suppose you could define java:false, just as well.

-Alan

by the way, I'm not sure about the handling of nil for method resolution even now, as there can be an ambiguity among different overloads when you pass null; I believe we should signal an error in that case, and I'm pretty sure we don't do it now.

Just my .02€ Alessio