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

Greg Beaver wrote: >> True, true. In hindsight it's perfectly obvious: A Factory method allows >> for the classes to be used to define the types, but the underlying >> implementation to be procedural (as is the case with the xmlrpc >> extensions and their setType function). I'd implement this with a >> factory method per class: >> XML_RPC2_Value_Base64::create >> but won't mind providing a shortcut method in XML_RPC2_Value (there's no >> XML_RPC2 base class). >> >> I'll summarize (once again) changes to XML_RPC2, after I get to analyze >> the profiling data in the basis of Greg's yesterday post. If I'm not >> forced to go with the setType solution, I'll change the API. > > > Common ground? :) I prefer the factory as well, but don't think we need > to go so far as to be procedural underneath in the PHP extension, I > would just like to see the factories only used by the end-user to > specifically control output rather than by the underlying implementation. It's procedural inasmuch as XML_RPC2_Value::factory returns an object for the PHP backend but a regular native (setType'd) type for the extension backend. Reminder: Please send me your profiling test cases, I'd like to optimize XML_RPC2 and you seem to have found some speed bumps. Cheers, -- Sérgio Carvalho