[s-xml-rpc-devel] Re: Bug in s-xml-rpc::encode-xml-rpc-call

[Sven Van Caekenberghe]

On 21 Dec 2005, at 23:14, Alain.Picard at memetrics.com wrote:

> Sven Van Caekenberghe writes:
>> Alain,
>>
>> If I understand your fix correctly, you want to interpret NIL
>> immediately as an empty array.
>> Before, NIL was interpreted as a boolean, no ?
>> What would be best ?
>> In CL, this very convenient fact (false == empty list) is a problem
>> when you want auto typing of arguments.
>
> Ah, darn, yes, I forgot that it was pulling double duty as a boolean.
>
> I did this without much tought, because what happened is that a
> test I had which used to run stopped running when I went from
> xml-rpc to s-xml-rpc, so I quickly discovered interpreting NIL
> as a symbol as the culprit.  Now I'm not so sure.
>
> Barring an "official" type mapping between lisp and XMLRPC,
> I guess it gets down to you to choose (and to document your choice).
>
> I think losing NIL as a boolean is too costly a price to pay,
> so perhaps forcing user code to use empty arrays instead of empty
> lists is an acceptable price to pay.
>
> So users would have to write code like this
>  (s-xml-rpc:encode-rpc-call "method" ...   (or foo #()) ... )
>
> which sucks, but, if they don't like it, they can use vectors
> instead of lists as the data type for foo.
>
> Other marshalling systems, e.g. CORBA, don't have these issues
> as they need to declare types up front as part of the method  
> signature.
>
> OK, well, thanks for reminding me of the true nature of the problem.
> Perhaps the best thing is to simply leave it as is.

OK, unless there are others with a different opinion, we will leave  
it at that for now,
the mailing list archive will keep a reference of this issue for  
future reference.

Sven