Optional method parameters

[fale...@gmail.com]

I was wondering whether json-rpc supported optional parameters, so I headed to the specification and found this (http://www.jsonrpc.org/specification):

> The absence of expected names MAY result in an error being generated.

Which, if I read it correctly, implies that optional parameters MAY be supported, but it's not mandatory to do so. Is that correct?

So, does qjson-rpc support optional parameters? How would they map to the C++ function signatures?

-----

As an alternative to optional parameters, I checked how would qjson-rpc react to parameters set to null in the json message being sent: I discovered that although you can serialize QVariant() (notice the empty parameters list), you cannot deserialize it.

I found the culprit to be at qjsonrpcservice.cpp:425, which reads

> if (!argument.isValid()) {

whilst it should probably read

> if (!argument.isValid() && !argument.isNull()) {

I tried it, and it appears to work.

I committed that change here: https://bitbucket.org/falemagn/qjsonrpc/commits/6385f3619ce4e6812139be4afe183d3c20c94946#Lsrc/qjsonrpcservice.cppT425

Before doing a pull request, though, I wanted to check with you guys if you deem that change correct.

Thanks for your attention,
Fabio

[Matt Broadstone]

Hi,

On Mon, May 2, 2016 at 11:27 AM, <fale...@gmail.com> wrote:

I was wondering whether json-rpc supported optional parameters, so I headed to the specification and found this (http://www.jsonrpc.org/specification):

> The absence of expected names MAY result in an error being generated.

Which, if I read it correctly, implies that optional parameters MAY be supported, but it's not mandatory to do so. Is that correct?

This basically means we can do whatever we want :) In this case the answer is yes and no: when using non-named parameters I believe we do not support optional parameters, when using named parameters we do.

So, does qjson-rpc support optional parameters? How would they map to the C++ function signatures?

This is generally why we have not up until now supported optional parameters when not using named parameters.

 

-----

As an alternative to optional parameters, I checked how would qjson-rpc react to parameters set to null in the json message being sent: I discovered that although you can serialize QVariant() (notice the empty parameters list), you cannot deserialize it.

I found the culprit to be at qjsonrpcservice.cpp:425, which reads

> if (!argument.isValid()) {

whilst it should probably read

> if (!argument.isValid() && !argument.isNull()) {

I tried it, and it appears to work.

I committed that change here: https://bitbucket.org/falemagn/qjsonrpc/commits/6385f3619ce4e6812139be4afe183d3c20c94946#Lsrc/qjsonrpcservice.cppT425

Before doing a pull request, though, I wanted to check with you guys if you deem that change correct.

That sounds that it might be a legitimate bug, but I can't link to your implementation (it's private). Would you be willing to put together an auto/unit test exhibiting the problem? This sounds like it might have been something missed during the conversion from QVariant-based API to the QJson-based API.

 

Cheers,

Matt

Thanks for your attention,
Fabio

--
You received this message because you are subscribed to the Google Groups "qjsonrpc-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qjsonrpc-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.