JSON-RPC 2.0 named parameters

[David]

The proposed JSON-RPC specification for named parameters could be
improved.

http://en.wikipedia.org/wiki/JSON-RPC#Version_2.0_.28Specification_Proposal.29


Here are two examples from the current proposal.

Procedure Call with positional parameters:

{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}


Procedure Call with named parameters:

{"jsonrpc": "2.0", "method": "subtract", "params": {"subtrahend": 23,
"minuend": 42}, "id": 3}


Why is "params" playing two roles here? Sometimes it's an array,
sometimes it's an object (dictionary). That can be confusing and will
complicate implementations.

This also prevents us from allowing methods that support both
positional and named parameters. This seems like a limitation that is
easy to overcome.

Named and positional parameters are two different beasts altogether.
It would make a lot more sense to separate them:

{"jsonrpc": "2.0", "method": "subtract", "params": [23, 42],
"options": {"subtrahend": 23, "minuend": 42}, "id": 3}

I placed the "positional parameters" into the "options" object. The
regular parameters are in the "params" array.

In Python the function definition would look like this:

def subtract(a, b, subtrahend=None, minuend=None):
pass

Is there any reason why the current proposal has this limitation?
Would it be better to cleanly separate these so that we can allow
methods such as the Python example I listed above?

[Matt (MPCM)]

I agree that jsonrpc doesn't currently map to the example you provided
well... though I am not entirely sure why you would want to send an
array for some of the parameters and an object for others... This came
up as part of the 1.1 spec.

But I am curious about the circumstances where having this ability
would be of benefit. Are there calls where you feel this ability would
be more clear or desired?

The potential for collision in this situation is very high, and there
would need to be very clear rules about how the values should settled
before performing the call.

--
Matt (MPCM)

On Jul 5, 2:40 pm, David <dav...@gmail.com> wrote:
> The proposed JSON-RPC specification for named parameters could be
> improved.
>

> http://en.wikipedia.org/wiki/JSON-RPC#Version_2.0_.28Specification_Pr...

[David Aguilar]

On Tue, Jul 5, 2011 at 5:28 PM, Matt (MPCM) <ma...@mpcm.com> wrote:
> I agree that jsonrpc doesn't currently map to the example you provided
> well... though I am not entirely sure why you would want to send an
> array for some of the parameters and an object for others... This came
> up as part of the 1.1 spec.

In Python the options "object" is a dictionary.
Dictionaries are how named parameters are implemented in Python:

http://docs.python.org/faq/programming.html#how-can-i-pass-optional-or-keyword-parameters-from-one-function-to-another

> But I am curious about the circumstances where having this ability
> would be of benefit. Are there calls where you feel this ability would
> be more clear or desired?

Yes. Named parameters let you rearrange/add/remove fields without
needing to go and change every caller. It also allows you to have
default values. Adding a positional argument requires you to change
every caller. It is very common to write methods that have both
positional (required) arguments as well as named (optional) arguments.

> The potential for collision in this situation is very high, and there
> would need to be very clear rules about how the values should settled
> before performing the call.

I think the rules used by Python are very clear. Python complains
loudly when *args and **kwargs map to the same variable and I imagine
that such behavior is outside the realm of the spec. The spec could
require that implementations generate an error whenever there is an
ambiguity.
--
    David

[Lorenzo Pastrana]

On Tue, 2011-07-05 at 18:23 -0700, David Aguilar wrote:
> > The potential for collision in this situation is very high, and there
> > would need to be very clear rules about how the values should settled
> > before performing the call.
>
> I think the rules used by Python are very clear.

What about C++, Java, C#, Javascript ?

=> no kwargs
=> mapping to ordered args
=> clash !

Again, json-rpc is a protocol, thus an effort toward aim not a simple
facility :)

Lo.

[David Aguilar]

Thanks Lo. Is there any way these can be rectified?

These languages require a mapping to ordered arguments.
How do they handle by-name arguments right now?

Would it work if the rule was that "params": [...] must come first and
"options": {} afterwards? Can this rule apply to these languages?

"no kwargs" and "mapping to ordered args" - the above rule could work
for these concerns

"clash!" - I'm not sure what can be done about this aside from saying
"don't do that". Is it a show-stopper?

Thanks for your help,
--
    David

[Lorenzo Pastrana]

> These languages require a mapping to ordered arguments.
> How do they handle by-name arguments right now?

They don't.

> Would it work if the rule was ...

Fact is that on one side there is a rule that says "you can do both but
not at the same time" and on the other a rule that would weight as much
as the rest of the spec to sort out all the exceptions etc .. just for a
feature that is a freak actually (IMHO).

> Now imagine what happens when the def gets changed to look like this:
>
> def sort(str_list, with_frobinator=False, case_insensitive=True):
> ...

The real question is why in the hell would you map it another way than :

{"jsonrpc": "2.0",
"id": 1,
"method": "sort",
"params": {
"str_list" : ["apple", "Apple", "banana"],
"with_frobinator" : false,
"case_insensitive" : true
}
}

> "clash!" - I'm not sure what can be done about this aside from saying
> "don't do that".

Btw : real programmers use tables ;P

Lo.