[armedbear-devel] jcall and t/nil boolean arguments

[Alan Ruttenberg]

On Fri, Jan 29, 2010 at 4:16 PM, Alessio Stalla <alessiostalla at gmail.com> wrote:
> On Fri, Jan 29, 2010 at 10:07 PM, Erik Huelsmann <ehuels at gmail.com> wrote:
>> Hi Alan,
>>
>> On Fri, Jan 1, 2010 at 9:37 PM, Alan Ruttenberg
>> <alanruttenberg at 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
>