[cl-json-devel] Question about NIL translation

[Henrik Hjelte]

> What about making the type argument to defun-json-rpc optional instead
> of mandatory.  If the default is explicit encoding then we'd still have
> backward compatibility without adding a new, more verbose-named defun?

yes, good idea. I had actually forgotten I had added some support for
different encoders in json-rpc.

I think the reason I don't had the type argument optional is because I
am a weak coder, I just don't  know how to make type &optional in the
right way. I guess you can put all three type lambda-list and body as
one &rest and parse it. On the other hand: I personally don't have a
strong problem with breaking backwards compatibilty in this way, it is
only for a small subset of cl-json and it breaks you old code in an
"nice" way, throwing an error that is easy to fix.

(defmacro defun-json-rpc (name type lambda-list &body body)

>
> The CL-JSON spec for 1.1 seems like a real mess --- it's not at all
> clear what should happen if you invoke a method over CL-JSON that
> returns a null value (e.g., a JS function with no return).
>
> The 2.0 (draft) spec seems to have a much clearer approach to this....
>
> I'm inclined to just move to observing the draft 2.0 spec.

Yes why not? I am not aware of the exact differences, except that 2.0
has named parameters.

Maybe it is possible to expose a function both as 1.1 and 2.0?

/Henrik