Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95111 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 27492 invoked from network); 13 Aug 2016 09:14:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Aug 2016 09:14:20 -0000 X-Host-Fingerprint: 80.177.120.119 marston-home.demon.co.uk Received: from [80.177.120.119] ([80.177.120.119:21696] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 19/08-55605-BE4EEA75 for ; Sat, 13 Aug 2016 05:14:20 -0400 Message-ID: <19.08.55605.BE4EEA75@pb1.pair.com> To: internals@lists.php.net References: <10fbcb03-5de8-4d9a-da1c-7e2bf77937cb@lsces.co.uk> <5657afc7-7569-5fc4-4a5a-27ed786c4fa5@gmail.com> <0825c173-5cb4-7f65-cf34-b45ca30919a3@lsces.co.uk> <8646c3ad-b929-cb0b-bad4-52a0a7160d16@gmail.com> <11ce571b-964b-5a3e-9f2f-3f69a8bc20b4@lsces.co.uk> <7d9db8d5-ae7a-4123-14f4-f76fb6d764c5@gmail.com> <1e14c4b9-65ce-4742-589f-19fe9290be0f@lsces.co.uk> In-Reply-To: Date: Sat, 13 Aug 2016 10:14:09 +0100 Lines: 7 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 16.4.3564.1216 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3564.1216 X-Posted-By: 80.177.120.119 Subject: Re: [PHP-DEV] Simple variable handling. From: TonyMarston@hotmail.com ("Tony Marston") "Peter Lind" wrote in message news:CAEU6NAdvBKMqhjU0aSsR5f+uBo9vvRyjYVJmr0ihxb8bDmG3Gg@mail.gmail.com... > >On 12 August 2016 at 12:13, Lester Caine wrote: > >> On 12/08/16 10:42, Peter Lind wrote: >> > On 12 August 2016 at 11:25, Lester Caine wrote: >> > >> > Thanks for the ideas on this feature. >> > >> > A few thoughts. >> > 1. The RFC for this isn't a change - it's an addition. If it gets >> accepted >> > and implemented, you still would not have to change your code if you >> didn't >> > want to. >> I think that is the whole point ... >> >> >You're making different points, so maybe you should then be clearer. > > > >> > 2. There are differing ways of using the language. Yours is not >> > better - >> > merely different. So I would think a relevant question is: can the RFC >> > in >> > point support your style of coding along with that of others. A >> > critical >> > point is throwing exceptions on invalid data, which might be hard to >> handle. >> Exceptions get generated hen something unhandled happens. Simple example >> 'divide by zero' only happens if the divisor is zero. If the variable >> used has a constraint of 'not zero' and has been validated then the >> exception will not be raised. My style would validate the divisor and >> only call the divide if it was going to work, others would allow the >> divide to fail and MAY actually handle the exception ;) >> >> >That doesn't address the point: if the feature should throw exceptions or >not, or allow for both styles. > > > >> > 4. I think your suggestions might conflate validation and sanitation - >> > these are not the same and cannot be handled as one >> That people try to inject malicious input via variables is a different >> problem. Firebird database has always preferred parameter data so SQL >> injections just don't work, but other stuff does need clearing when >> input rather than simply relying on escaping unprocessed output. Again >> it's programming sytle? >> >> >No, it's not programming style. Conflating validation and >sanitation/escaping is wrong, because the contexts are different. > > > >> > That said, I generally think that built-in methods that accept >> > Callables >> > are a great way to go. It encourages reuse through modular >> > composition - >> > and could likely be a neater way around the throw exception/return >> > error >> > code issue. It's obviously doable from userland, but could probably be >> > improved if implemented in the language. >> >> It was the fact that Yasuo was adding these rules into his array >> validation stuff that just grates so badly with what is actually needed >> ... >> >> >> >Yasuo was presumably scratching an itch that he (and possibly others) feel. >As such, it is in fact "what is actually needed". It just doesn't happen to >be what *you* actually need, but that doesn't mean it won't fit perfectly >for many others. > Define "many". Is it 1% of the total number of PHP programmers, or is it 51% ? I do not see that complicating the language by making it do what SHOULD be done in userland code is a good idea. Helping 1% of users while hindering the remaining 99% is not an idea which should EVER be contemplated. -- Tony Marston