kwparams and named parameters

[Weston Ruter]

To start a dedicated thread to the discussion of named parameters.

On 10/1/07, Skylos < sky...@gmail.com> wrote:

...
I think the named and positional parameter options are confusing. I
like having a single point of entry.  I'd vote for deprecating the
combination and at the same time keeping the parameters to a single
property name.  I think it is simpler to keep one input parameters
name.

I agree that we should abandon a separate "kwparams" property for storing named parameters. However, I strongly feel that named parameters should be kept. Allowing for named parameters gives a lot of flexibility in both designing and accessing JSON-RPC services. 1.1ALT states, " 1.1WD allows mixed named and positional parameters, which requires much more complicated servers and clients and adds some ambiguity." However, it isn't that difficult to implement an algorithm to pick out the positional and named parameters. If the logic is too difficult, we could simply provide an algorithm in the spec to aid implementors, as WHATWG has done in Web Forms 2.0.

I wrote a succinct algorithm in a PHP server implementation obtaining named and positional parameters from a single "params" property. Note that in order for this to work, I used the PHP tokenizer functions to parse out the names of the parameters in the function prototypes. If a programming language doesn't have a tokenizer or some other method of self-introspection, then some method of manually providing the parameter names would be required. So since named parameters may be difficult for some programming languages to support, perhaps the spec should state that servers SHOULD accept named parameters but not require it.

From RPCServer.class.php:

#Iterate over the function's defined parameter list
for($i = 0; $i < count($parametersForPrivateProcs[$privateProcName]); $i++){
    $param = $parametersForPrivateProcs[$privateProcName][$i];
   
    #Named request parameter matches
    if(isset($requestParams[$param['name']])){
        array_push($paramsToPass, $requestParams[$param['name']]);
        unset($requestParams[$param['name']]);
    }
    #Numbered request parameter matches
    else if(isset($requestParams[$i])){
        array_push($paramsToPass, $requestParams[$i]);
        unset($requestParams[$i]);
    }
    #Provide default for missing parameter if provided and if default values are preserved
    # This ability is not specified by 1.1 WD as it requires that NULL be supplied as default
    else if($this->defaultParametersPreserved && isset($param['default'])){
        array_push($paramsToPass, $param['default']);
    }
    #Supply NULL for missing parameter
    else {
        array_push($paramsToPass, null);
    }
}

[Jeffrey Damick]

I also agree with not having the kwparams and dropping the mixed positional / named params, that is just over complicating matters..  If we say the server should support named and must support positional, then we give a slightly easier migration path for existing json-rpc libraries.

[Matt (MPCM)]

I am in total agreement with that statement.

I do not see much harm in requiring 1.1 servers *must* support named
params, as otherwise they are basically running a 1.0 server at that
point. But a point I won't bicker over in the slightest.

--
Matt (MPCM)

[Skylos]

On 10/2/07, Matt (MPCM) <Wicke...@gmail.com> wrote:
>
> I also think we should drop using both and I'd go a step further...
>
> How do people feel about multi purposing the params field be an array
> (positional) or an object (named)?

I like this idea. Objects with numeric keys look funny to me. If it
has a position, it should be in an array, and if it has a name, it
should be in a hash/object.

It introduces an inherent ambiguity - what if I have a named parameter
'2' in the third position. It becomes impossible to supply a value
for it! I admit its somewhat unusual to use numbers for names, but
should we actually restrict you from doing that by forcing a numeric
name to be a parameter? I say no.

> Do we need to have 2 names for the
> same concept of passing a structure of values to be applied as
> parameters?

Thats an interesting problem that complicates strongly typed
languages. That is, you'd have to have some kind of generic factory
or object for managing the retrieval of the parameters value as you
never know whether its going to be an object or an array. It bears
consideration, perhaps.

David

[Jeffrey Damick]

Right, take that part from WD 1.1, just use: "params" as the name.. it's simple to detect [ vs. {   :)

On 10/2/07, Matt (MPCM) <Wicke...@gmail.com> wrote:

I also think we should drop using both and I'd go a step further...

How do people feel about multi purposing the params field be an array

(positional) or an object (named)? Do we need to have 2 names for the

same concept of passing a structure of values to be applied as
parameters?

--
Matt (MPCM)