Re: Re: 1.1WD suggestions update

So the only bad thing is that by adding kwparams and removing the named arguments capability from params is that it is a pretty big change if you've already implemented 1.1WD and have it running in several environments (like me).. ; This type of divergence from 1.1WD would prevent me (and probably others) from adopting it.  While i see the point about kwparams being more explicit than params, i think { vs. [ is just as easy to visually identify.  Maybe kwparams could only apply if you trying to mix them..


-jeff

On 5/6/07, r.koebleryahoo.de">r.koebleryahoo.de < r.koebleryahoo.de">r.koebleryahoo.de > wrote:

On Sun, May 06, 2007 at 03:30:53AM -0000, jimcburg wrote:
&gt; I'm guessing that you are just checking whether people are actually
> reading the thing, but you have "params" identified with "by-name" and
> "kwparams" identified with "by-position&quot;.
oh, thanks. it's corrected now.

> Presuming that "Extensions"; are optional,
yes, they are optional.

> Overall, except a few minor edits, I give your recommendation a +1.
thanks .

regards,
Roland

I also have JSON-RPC 1.1 working and it works great. kwparams would
be a breaking change (not to mention I think "kwparams" is an
inelegant identifier that doesn't fit with the rest).

I agree with Jeffrey: having just the one params object
differentiated by type { vs [ would make more sense for me. I never
understood the need for mixing them anyway. It seems like an
unneccessary complication to accommodate a very wierd usage.

--- In json-rpc%40yahoogroups.com">json-rpcyahoogroups.com, "Jeffrey Damick&quot; <jeffreydamick...>
wrote:
>
&gt; So the only bad thing is that by adding kwparams and removing the
named
> arguments capability from params is that it is a pretty big change
if you've
&gt; already implemented 1.1WD and have it running in several
environments (like
&gt; me).. This type of divergence from 1.1WD would prevent me (and
probably
> others) from adopting it. While i see the point about kwparams
being more
>; explicit than params, i think { vs. [ is just as easy to visually
identify.
> Maybe kwparams could only apply if you trying to mix them..
&gt;
>
> -jeff

On Mon, May 07, 2007 at 03:46:59PM -0000, Stephen M. McKamey wrote:
&gt; (not to mention I think "kwparams" is an
> inelegant identifier that doesn't fit with the rest).
if you know a better name: tell me.

&gt; I agree with Jeffrey: having just the one params object
> differentiated by type { vs [ would make more sense for me.
ok. but this would mean that you cannot mix named and positional
parameters. that would be ok for me, and I already suggested that
some time ago -- but since some people said they need this mixing,
I added kwparams...

> understood the need for mixing them anyway. It seems like an
> unneccessary complication to accommodate a very wierd usage.
here are some examples of RPC-calls with and without mixing:
(in python-syntax)

- with mixing:
sum(23,42)
sum(23,42, debug=False)
echo(&quot;test&quot;, times=10)

- without mixing, these would look like:
sum(23,42)
sum(23,42, False)
sum(s1=23, s2=42, debug=False)
echo(&quot;test&quot;, 10)
echo(content=&quot;test&quot;, times=10)

this i.e. means, that if you use parameters by-position, and want to add
a named parameter, you have to completely switch to named parameters.

so, if we don't need the "with-mixing&quot;-sytax, we could again
drop kwparams, and always use params as array or object.
(but there **won't be mixed-parameters in params** like in 1.1WD!)

I created a poll for this.

regards,
Roland