Request for clarification about named and positional parameters
Robert Goldman
"The position and name of a parameter is defined by the formal
argument list of the procedure."
I'm not sure how to read this, since the spec is silent on what is a
formal argument list. Indeed, absent a notion of introspection, there
really is no such thing as a formal argument list for a procedure,
right? We have just a transport protocol, and once the request
objects arrive at a destination that implements the procedure call,
it's completely up to the destination to parse the arguments as it
will.
For example, it would be possible for me to implement a server that
would case-flatten named parameters, and treat fooBar, foobar, and
FOOBAR as the same parameter....
If introspection were to be added, of course, the spec would need to
be tightened.
Best,
r
Matt (MPCM)
position and/or corresponding variable token is defined by the server.
Or something along those lines. A clean api would probably have some
expected input, but it could be variable.
1.0 only supported sequential parameters.
2.0 supports names as well to allow the concepts of default values and
out of order mapping from the incoming json object.
But it is possible the functions on the server could be non-descript
in what they are expecting and never have a 'formal' definition. I'm
thinking primarily of server side js and the arguments property.
As for the names of the parameters having case collisions during
reduction... this is dependent on the language restraints are doing
the processing. JSON would certainly allow a call with {"myVar":1,
"MyVar":2, "MYVAR":3}, the language on the server may not. But seeing
as the server is doing the processing, it should follow the natural
rules of the language. My suggestion would be to match the case used
by the function.
--
Matt (MPCM)
Robert Goldman
> Good point here, this should probably be cleaned up to say that the
> position and/or corresponding variable token is defined by the server.
> Or something along those lines. A clean api would probably have some
> expected input, but it could be variable.
>
> 1.0 only supported sequential parameters.
>
> 2.0 supports names as well to allow the concepts of default values and
> out of order mapping from the incoming json object.
>
> But it is possible the functions on the server could be non-descript
> in what they are expecting and never have a 'formal' definition. I'm
> thinking primarily of server side js and the arguments property.
My suggestion would be that we can get away with nondescript as long as
we don't do anything like discovery. Once we add some kind of
introspection methods --- which seems like an obvious extension, and one
that's present in xml-rpc --- we are likely to need to be much more
clear about how a procedure advertises itself, and what is a parameter list.
>
> As for the names of the parameters having case collisions during
> reduction... this is dependent on the language restraints are doing
> the processing. JSON would certainly allow a call with {"myVar":1,
> "MyVar":2, "MYVAR":3}, the language on the server may not. But seeing
> as the server is doing the processing, it should follow the natural
> rules of the language. My suggestion would be to match the case used
> by the function.
I wasn't actually suggesting that one have case-insensitive parameter
names; I was just pointing out that there's nothing in the spec that
prohibits it.
Thanks for answering all of these questions!
Best,
R
Vladimir Dzhuvinov
On Jan 5, 12:12 am, Robert Goldman <rpgold...@gmail.com> wrote:
> I wasn't actually suggesting that one have case-insensitive parameter
> names; I was just pointing out that there's nothing in the spec that
> prohibits it.
Under "2. Conventions" it actually says
"All names (i.e. method-names or parameter-names) are case-sensitive."
~ Vladimir
--
Vladimir Dzhuvinov
www.dzhuvinov.com