Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19999 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63942 invoked by uid 1010); 15 Nov 2005 13:33:20 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 63927 invoked from network); 15 Nov 2005 13:33:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Nov 2005 13:33:20 -0000 X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from ([80.74.107.235:30653] helo=mail.zend.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 65/D9-07637-E93E9734 for ; Tue, 15 Nov 2005 08:33:19 -0500 Received: (qmail 29937 invoked from network); 15 Nov 2005 13:33:14 -0000 Received: from internal.zend.office (HELO ?127.0.0.1?) (10.1.1.1) by internal.zend.office with SMTP; 15 Nov 2005 13:33:14 -0000 Message-ID: <4379E396.9070003@zend.com> Date: Tue, 15 Nov 2005 16:33:10 +0300 User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Roman Ivanov CC: internals@lists.php.net References: <84.9C.07637.EEB48734@pb1.pair.com> <6A.CC.07637.49C48734@pb1.pair.com> <437932CE.80000@zend.com> <4B.67.07637.41949734@pb1.pair.com> <4379AE54.1080808@zend.com> <8F.F8.07637.B9FD9734@pb1.pair.com> In-Reply-To: <8F.F8.07637.B9FD9734@pb1.pair.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: results of the PHP6 wishlists From: antony@zend.com (Antony Dovgal) On 15.11.2005 15:06, Roman Ivanov wrote: > This particular extension treats each input variable individually, which > is not desirable in majority of scripts I worked with. Such approach > adds unnecessary complexity to the script, and requires to handle each > invalid variable separately as well. But the real problem is that there > are many ways of filtering input, and I do not think any of them fits > all the situations. Ahha. So what exactly do you propose? For example, I have 3 different variables: an email, an integer and a string. How do you think I should filter them ? > >> "Part of the standard API, which is included with PHP and compiles by > >> default", if you will. > > > > > > So, basically you're objecting against enabling it by default? > > Why? I really do not see a reason to not include it by default, if it > > helps to write more secure code. > > (remember that "enabled by default" means you can disable it in a > moment). > > Well, I think that everything in core distribution is a suggested > standard. But a language should not, in my opinion, suggest any > particular structure for the program, unless it's absolutely necessary. > It's not a major issue, but still... Sorry, I refuse to understand that. The language HAS to recommend a way to do something and to allow user to choose any other way if the recommended one doesn't fit his/her needs. If there is no a recommended way to do, for example, input filtering, users would re-invent the wheel every time, which results in square wheels and engines with security issues discovered every day. That's the whole point: to provide a fast and comfortable way to filter data, so the users won't have to do it themselves. Feel free to offer an improvements, if you have something to offer, but saying that a standard method of doing something *imposes* a particular structure is just a nonsense. -- Wbr, Antony Dovgal