Re: Mod 10 for Payment package?

I wrote a cc validation class a couple weeks ago but a little busy so I haven't had time to add the phpdoc comments yet. It does the Luhn Check (I think this is what is also referred to as Mod 10), validates expirations, validates major cc issuers ) visa, mc, amex, discover, diners, jcb, enroute...) and more. I don't have a good place to upload the source to, but here is the method list which may give you an idea of what I wrote.: _isIssuer($cardNumber = NULL, $issuer = NULL) _issuerCategories() _LuhnCheck($cardNumber = NULL) errorMessage($value) filterNonDigits($source = NULL) getIssuer($cardNumber = NULL) getIssuerCategory($cardNumber = NULL) isAmericanExpress($cardNumber = NULL) isCarteBlanche($cardNumber = NULL) isDinersClub($cardNumber = NULL) isDiscover($cardNumber = NULL) isEnRoute($cardNumber = NULL) isError($value) isJCB($cardNumber = NULL) isMasterCard($cardNumber = NULL) isUnknown($cardNumber = NULL) isVisa($cardNumber = NULL) validateCard($cardNumber = NULL, $expMonth = NULL, $expYear = NULL) validateExpiration($expMonth = NULL, $expYear = NULL) validateNumber($cardNumber = NULL) Once I find a way to share my source with you that all will make more sense. I have it as a static utility class and have been wanting to include into PEAR but don't currently have a good home to serve an official proposal from. All the methods are complete and functional. Methods such as isVisa return true | false or PEAR Error if any required input is missing (maybe should just return false per earlier comments in this thread?) If there is any interest in viewing the source I am willing to send it to individuals as requested (don't want to bog down list with source). If not interested no hard feelings. I am willing to allow anyone else in PEAR to use anything they may like from it if a different package model is desired (with proper credit given for my contributions, of course). --Mike "Bertrand Mansion" <bmansion@mamasam.com> wrote in message news:BB8E5556.CAD5%bmansion@mamasam.com... <joe@joestump.net> wrote : > My only point is this: why have a great error handling class if you > aren't going to use it? PEAR should push things up a notch as far as > quality and I think that when I'm coding a PEAR_Error class offers so > much more to me as a coder than true/false does. In order to have Validate compatible with other packages, whether they use pear or not, it's better to have each validation methods return a boolean. For example, QuickForm users can use the Validate package to validate a date, a credit card, etc. The logic is : is my data valid, yes or no ? We don't need or want to know why. Furthermore, using PEAR_Error is against the Keep It Simple principle. Bertrand Mansion Mamasam