Re: Mod 10 for Payment package?

From: Date: Wed, 17 Sep 2003 10:23:41 +0000
Subject: Re: Mod 10 for Payment package?
References: 1 2 3  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-21628@lists.php.net to get a copy of this message
On Wednesday, September 17, 2003 10:49, Pierre-Alain Joye wrote: > On Wed, 17 Sep 2003 10:41:29 +0200 > "Stefan Neufeind" <stefan@neufeind.net> wrote: >> For sure your contributions are always welcome. But maybe Joe could >> have a look at it, compare it with his ideas and if he has further >> contributions / checks / ... could streamline all the up-coming >> ideas? > Yeah go ahead to commit changes according to our discussion. Once you > are ready mail me, then I'll launch a new alpha release. > It will be easier for you to get feedbacks. > One important point about Validate is it will always return true/false. > It is the main idea behind it. However subclasses may provide more > informations about what is wrong in a given data. Tomas, agreed? If there will be functions returning error codes, I guess that would be better to normalize this situation to all functions. If error codes starts from -1 to -n, the look will be: Simple check: if (Validate::foo('bar') < 0) { die("invalid 'bar'"); } Complex check: $error = Validate::foo('bar'); if ($error == VALIDATE_FOO_TOO_SHORT) { die("'$bar' was too short"); // or even provide error messages die(Validate::getMessage(VALIDATE_FOO_TOO_SHORT)); // other idea die(Validate::getLastErrorMessage()); } I'd use VALIDATE_<FUNCTION>_MSG for the convention. The objective of the class was simplicity of checking, but I agree that many people need or want to have precise info about the error. It's up to you Pierre, I'm just giving ideas :) -- Tomas V.V.Cox mailto:cox@idecnet.com

« previous php.pear.dev (#21628) next »