Re: [PEPr] -1 for XML::XML_RPC2

Greg Beaver wrote: > I find this decision rather simple: if there are any non-sequential or > non-numeric indices, struct is used, otherwise array is used. It's not acceptable. I do exactly that when doing automatic encoding, but I assume it may be a bad decision. I mean, if you do this: $proxy->foo(array('bar','baz')); the call payload will carry an array. However, the server may be expecting a struct and will barf out if presented with an array. In XML_RPC2 you can workaround these cases by avoiding automatic encoding, and specifying the type itself: $proxy->foo(new XML_RPC_Value_Struct(array('bar', 'baz'))); I realize the extensions do this using setType. That approach strikes me as smelly. Why represent the concept of type using a band aid when the language provides me with a native form of representing types? >> - PHP Strings to either XML-RPC string or XML-RPC base64 string. > > > This must be developer-based. I don't think you understand what I was > saying with my comments on OO - you thought I was talking about XML_RPC2 > when I was explaining what makes something OO, but I was talking about > Chiara_XML_RPC5. Email is not always the clearest medium. > > The way I have people do this in Chiara_XML_RPC5 is: > > <?php > $xmlrpc = new Chiara_XML_RPC5('ªdXÞºO˜Ço}¨ > Sá–~http://example.com/xmlrpc.php'); > $arr = array(1,2,'base64'); > $xmlrpc->setType($arr[2], 'base64'); > $result = $xmlrpc->someFunction($arr); > ?> Isn't it much cleaner to do: <?php $xmlrpc = new XML_RPC2_Server('http://example.com/xmlrpc.php'); $xmlrpc->someFunction(1,2, new XML_RPC_Value_Base64('base64')); ?> I personally don't like setType. It strikes me as procedural. A workaround for not being able to set the parameter type on the call line itself. My solution leverages the ability of creating your own types (classes, nonetheless) to allow the package user to express what he means in one go. >> - PHP ints to either XML-RPC int or XML-RPC dateTime. > > > Same as above example but use 'datetime' All of the three problematic cases are the same original problem. We can limit discussion to 'base64' for example. > For the server end, the server has to create the values and use setType > in the same manner. The server end poses no problem, because there is a direct mapping. Each XML-RPC type is represented by only one PHP type. > For other values, php provides clearer alternatives such as casting to a > double from a string. -- Sérgio Carvalho