Re: XML_RPC2 and class profileration, or the myth of require_once

Sergio Carvalho wrote:

Joshua Eichorn wrote:

For me the concern isn't as much about speed as its about usability. You have more public classes then ext/Soap has public methods and if anything Soap is more complex then xmlrpc.

Server, Client and the XML_RPC_Value classes. They're all necessary, I don't see how you can do without them.

Use of XML_RPC_Value_* could possibly be made optional. For special types such as base64, a XML_PRC_Value_Base64 can always be asked/returned, otherwise a simple gettype() could be used. All XML_RPC_Value_* classes should still be supported, may be for something as simple as factory() method purpose. I don't see any reason why this package should be shoot down just because it allows room for a certain solution. In any case, this package proposal should be expanded and not merely switched to another incompatible design. This probably mean a refactoring of the current code.

That in itself shoudl lead us to question the design. PHP is not Java and any design that looks like its a direct java port is going to recieve from flack (rightly or not).

Yes, PHP developers should compare the Java API with the PHP API and take some lessons (hint: Type classes are there). That is an war I don't want to buy, however.

Yes, maybe there are lessons to be taken from Java. However, because Java and PHP are so inherently different not everything should be carried over verbatim from Java to PHP. Things like lot of class files are a none-issue with Java, but can become a burden in PHP. -Philippe