Re: please vote - package-proposal Payment_IBAN
| From: | Stefan Neufeind | Date: | Wed, 06 Aug 2003 19:45:33 +0000 |
| Subject: | Re: please vote - package-proposal Payment_IBAN | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-19337@lists.php.net to get a copy of this message | ||
On 6 Aug 2003 at 19:37, Pierre-Alain Joye wrote:
> On Wed, 06 Aug 2003 19:21:52 +0200
> "Stefan Neufeind" <Neufeind@speedpartner.de> wrote:
>
> > I'm against Validate. It's also "parsing" - and in the following
> > than just "apply a regex" (like email-validation and similar). Also
> > extraction of certain data (e.g. "extract bankcode") doesn't belong
> > in Validation I would say.
>
> Validate does much more in many situations than just apply a regexp...
Okay, maybe in some cases. But e.g. for checking email-adresses and
similar that does the job. That was my view of the Validate-package.
> > And last: Validation would get really too bloated. The only way I
> > could think of to integrate the current IBAN-stuff would be a
> > separate Validate_IBAN-class (and having Validate not as a class but
> > as a tree-hierarchy in the index). Well, but anyways ... Validate
> > (see explanation above) is out of discussion, right?
>
> No. There is already other validation methods that have non static
> validation. I mean that requires to update/get some data before doing
> the validation.
Also creation of new numbers etc.? Well, I wouldn't say that all this
functionality belongs under "Validate" because that's quite
misleading.
And again: Having a specialised class would be the best in my eyes.
Also it would make maintenance easier.
What do the others on the list vote for? Using Payment_IBAN and
implementing all functionality on that level (incl. generate, gets,
modifications, ...) or use "Validate" which might be misleading if
you stuff all the functionality there?
Please comment! The class is ready for a first release - and we need
the functionality of it in a project. So getting feedback soon would
help avoiding much much changes later.
Stefan