Re: New hierarchy for payment processors?

On Mon, 24 Jul 2000, Stig Sfther Bakken wrote: > PEAR is intended for exactly this kind of thing. It's ok to have it in > the main CVS right now, but I think we should move most of the classes > out to separate distributions when the tools are done. Hi Stig, thank you. You'll probably have noticed I've committed Payment/Verisign.php to the CVS tree now. I've put a big "DO NOT USE" across the top as I'd like to solicit any input from you guys and from my co-developer on the pfpro extension before I go any further. I like the idea of being able to package up the extension's C files and the related php files together and distribute them as a single package. Presumably this relies on dynamic loading in PHP which I have yet to play with. I also like the concept of returning Exception objects, but I just know people won't bother to check them on every method call. Do you think the Zend guys would go for a Java-like throw/try..catch exception mechanism? I was wondering about the @param and @return comments in some of the pear files. Is there some kind of tool already written to parse these? They look about like javadoc I think, but I have no experience with that. Finally... the Payment/Verisign class is useless without the pfpro extension installed. I've put a check for this in the actual process() method, but I was wondering whether it would also be good form to do something like this, outside of the class definition so it checks when the file is loaded: if (!extension_loaded('pfpro')) { die('Payflow Pro module is not compiled into PHP. Compile PHP using --with-pfpro.'); } Regards, David. -- |> /+\ \| | |> <Zeev> I'd rather die than make PHP 5.0, thank you :)