Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95083
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <ab77510e-bcd9-fdee-5a66-dcba2baba0b4@lsces.co.uk>
References: <10fbcb03-5de8-4d9a-da1c-7e2bf77937cb@lsces.co.uk>
 <CAEYWF=4kkvmp8TCmRhdhzzM-sWpk+-sYE7u2eP1Jf3NkshFiJA@mail.gmail.com>
 <CABdc3WqYeoXoHL-E4adjoZTVr1bs1CHfRaDmoqtmpGW7yREmUA@mail.gmail.com>
 <c76f0716-4881-4aae-2fbd-f1af70fd6114@lsces.co.uk> <CANUQDCjaXeJsCAjyE+q-UhXCFjexwRYWLKzMfwRQVDaEwVbLog@mail.gmail.com>
 <d67a6ee8-4fbe-9583-3bac-d2e98298663f@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>
 <a25c0473-aa5f-7a1a-d1c9-0c8eebfd1188@lsces.co.uk> <bbe11a4d-26ce-e140-52d0-71d7afbffbba@gmx.de>
 <1e14c4b9-65ce-4742-589f-19fe9290be0f@lsces.co.uk> <CAEU6NAdh42oxiDRUJRVekcEAadiqsQYXYQUDE7XOg3WLQMsXPg@mail.gmail.com>
 <ab77510e-bcd9-fdee-5a66-dcba2baba0b4@lsces.co.uk>
Date: Fri, 12 Aug 2016 12:23:31 +0200
Message-ID: <CAEU6NAdvBKMqhjU0aSsR5f+uBo9vvRyjYVJmr0ihxb8bDmG3Gg@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0d49966d3ab00539dd47d6
Subject: Re: [PHP-DEV] Simple variable handling.
From: peter.e.lind@gmail.com (Peter Lind)

--94eb2c0d49966d3ab00539dd47d6
Content-Type: text/plain; charset=UTF-8

On 12 August 2016 at 12:13, Lester Caine <lester@lsces.co.uk> wrote:

> On 12/08/16 10:42, Peter Lind wrote:
> > On 12 August 2016 at 11:25, Lester Caine <lester@lsces.co.uk> 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.

Regards
Peter


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

--94eb2c0d49966d3ab00539dd47d6--