The only fair comparison is PHP -- the other languages track information about what the type of the variables are, which is where SOAP in perl falls down. Perl is not a strictly typed language, and so SOAP::Lite tries to guess what you intended.

Sometimes it's right, sometimes it's not. Just like Perl -- sometimes the DWIM doesn't work. Perl has no concept of a boolean type, nor easily discernable differentaton between a float, integer and string -- they're all just scalars. As for the gensym bits, it's because it has no element name to use, because of the way arrays and hashes are handled in Perl. You don't need named structures, like some other languages. So it randomly inserts something for you. Is that the best solution? Maybe. Perhaps it should have a 'strict' option where it dies anytime it has to make an assumption about what you wanted, so you could see where you didn't cast every last item that might be ambiguously interpreted

And I don't think I ever said abandon the WSDL -- in fact, if you check the soapbuilders list, I believe that the general concencus is to use the WSDL as a starting point, but not necessarily as-is -- copy it, modify it to work for your toolkit, and point to that. The problem is if the server should change their WSDL, but odds are, that'd break things anyway.

And you don't have to hack the serializer if you follow the instructions in the SOAP::Lite documentation for casting data using SOAP::Data. I don't have that luxury, because I have a SOAP aggregator, which gets its data from a SOAP server, and passes it back out, so it was easier to hack the Serializer. There are methods to give extra conditions or change the precidence of items -- use it, it's what they're there for.

Personally, I'm working on moving all of my services over to document/literal, rather than rpc/encoded. Of course, I have the advantage that I control all of the servers (but not all of the clients)