Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100413 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 47060 invoked from network); 6 Sep 2017 12:06:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Sep 2017 12:06:07 -0000 Authentication-Results: pb1.pair.com smtp.mail=php-lists@koalephant.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=php-lists@koalephant.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain koalephant.com designates 206.123.115.54 as permitted sender) X-PHP-List-Original-Sender: php-lists@koalephant.com X-Host-Fingerprint: 206.123.115.54 mail1.25mail.st Received: from [206.123.115.54] ([206.123.115.54:33600] helo=mail1.25mail.st) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5A/A4-10715-CA4EFA95 for ; Wed, 06 Sep 2017 08:06:07 -0400 Received: from [10.0.1.22] (unknown [49.48.241.143]) by mail1.25mail.st (Postfix) with ESMTPSA id 8F7CC60503; Wed, 6 Sep 2017 12:05:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 6 Sep 2017 19:05:53 +0700 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: References: <0C7F986C-B0BC-4315-98ED-B4FD003B9399@gmail.com> <2a4491b4-e6f5-4297-beec-363f373a93e6@lsces.co.uk> <3f8be7b1-0e59-21c6-4fe8-8299b2c05645@rhsoft.net> <6ba62d62-f1ab-9e7b-93f0-a1a9238c47a6@lsces.co.uk> <0db9cfa3-2b31-ee41-713c-889b7cc06406@lsces.co.uk> To: Rowan Collins Subject: Re: [PHP-DEV] A validator module for PHP7 From: php-lists@koalephant.com (Stephen Reay) > On 6 Sep 2017, at 18:15, Rowan Collins wrote: >=20 >> On 6 September 2017 09:29:37 BST, Lester Caine wrote= : >> My only problem with Yasuo's latest offering is once again it adds a >> whole new set of defines that have to be mapped to existing metadata >> definitions ... That and it is a lot of longhand code using a different >> style to existing arrays. We need yet another wrapper to build these >> arrays from existing code ... >=20 > The rules have to be defined somehow, and I'm not aware of a standard form= at that current code is likely to follow. Unless there is already such a sta= ndard, I can't see any way to avoid existing code having to be wrapped or am= ended. >=20 > Which is why Yasuo and I have both suggested we work together to come up w= ith such a standard format that can be used or adapted for these different p= arts of the application. If you have suggestions for how the format should l= ook, we are eager to hear them and see some examples. >=20 > Regards, >=20 > --=20 > Rowan Collins > [IMSoP] >=20 > --=20 > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >=20 Does this proposal actually offer any improvement over what's available with= filter_var/etc and a userland wrapper class? If there are deficiencies in how the existing filters work, maybe work on de= tailing the issues and then fixing/improving them? That way, all the userland validation currently built around them, needs *po= ssibly* minor changes to make use of new flags/options, as opposed to a comp= letely new API to use. Cheers Stephen