Loading ...
Sorry, an error occurred while loading the content.

Re: [json-rpc] 1.1WD: A short, impassioned plea against positional arguments

Expand Messages
  • Jim Washington
    ... This was met with deafening silence. I would like to keep this proposal in play. Remember, the whole point of this exercise is to enable method calls in
    Message 1 of 10 , Mar 8, 2007
      I proposed:
      > Here's another take. IMHO it has simplicity, yet also has the
      > extensibility I want.
      > How about we do not change the "params" parameter at all from 1.0, and
      > separate out the named parameter stuff into another member of the Call.
      > In this proposal, "params" should continue to be the *optional* Array of
      > positional parameters, just like in 1.0. This would mean almost zero
      > trouble for clients and servers that still speak 1.0 - no
      > backward-compatibility problems of getting an Object when an Array is
      > expected.
      > Keyword (named) parameters, if desired, will be transmitted as an
      > *optional* member of the Call named "kwparams". The "kwparams" member
      > is always an Object like {"parameterA":valueA,"parameterB":valueB}.
      > Named parameters do not need to be supported if you do not wish to use them.
      > So, in this proposal, named arguments and positional arguments are
      > separate, and optional, and their container is of a known type. You can
      > use both, together, if you wish. Remember, it is the server that decides
      > what the procedure call signature is. If something is impossible or
      > impractical, don't use it.
      > Anyway, this makes moot the discussion of whether to support one or the
      > other or both. All parameters in this proposal are optional, and there
      > is a way to send whatever type meets your current coding philosophy.
      > Hopefully, this will simplify things for both client and server side
      > implementations, as well.

      This was met with deafening silence.

      I would like to keep this proposal in play. Remember, the whole point
      of this exercise is to enable method calls in whatever language the
      server is using. The server program determines what the call signature is.

      Allowing keyword parameters allows call signatures like, in python:

      dothis(a, b, c, d=17, e="Hello world", debug=False, verbosity=1)

      Python permits default values for parameters. If a keyword parameter
      (one with a default value) is left out when the method is called, the
      default value is used. This is useful in many cases.

      The sense I get from this list is that very few like the polymorphic
      "params" member. Those that like named parameters want it only to be a
      JSON object, and those that like or only can use positional parameters
      want it only to be a JSON array. In any case, a server implementation
      needs to inspect the construction of "params" and perform different
      logic depending on what it finds.

      In addition, making this happen according to the current WD also makes
      the client application complicated. I am not aware that anyone has
      succeeded with a fully working implementation of 1.1WD in client
      javascript, and this is likely to be the most-often-used language for
      clients. The idea that "params" can be an array or an object makes
      updating to 1.1 difficult to sell, because it requires simultaneous
      upgrades to both client and server. If an upgrade to dojo all of a
      sudden started sending 1.1-style JSON objects as the "params" member,
      anyone using a server implementation that only supported 1.0 would have
      to stop getting upgrades to dojo. And no, having {"version":"1.1"} in
      the call does not help, because 1.0 server implementations do not need
      to look for that.

      The above proposal is an incremental and easy change to allow call
      signatures with keyword parameters.

      For example, in dojo, I can see an addKwParams method in its existing
      JSON-RPC infrastructure to add the functionality in this proposal:

      Where, currently, a method in client dojo may look like:


      it could easily look like:




      Here, the dojo library would only need to create the addKwParams method
      in the jsonrpc object, and add the "version" and "kwparams" members of
      the JSON-RPC call as necessary to meet requirements for 1.1. The person
      writing the javascript for the particular application would add keyword
      parameters only if reasonable for the particular server implementation,
      and only if it makes sense for the method call signature.

      Please consider this proposal. It removes most of the objections to
      named parameters, keeps things simple, and has a good chance of being
      acceptable to client libraries.


      -Jim Washington
    Your message has been successfully submitted and would be delivered to recipients shortly.