Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95089
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <d3184b54-7c9b-98d2-bece-ce1633a95e39@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> <CAEU6NAdvBKMqhjU0aSsR5f+uBo9vvRyjYVJmr0ihxb8bDmG3Gg@mail.gmail.com>
 <d3184b54-7c9b-98d2-bece-ce1633a95e39@lsces.co.uk>
Date: Fri, 12 Aug 2016 13:06:51 +0200
Message-ID: <CAEU6NAdhex8etRSG5uQLEQYJed26rHGkSppAJu9sxmgdDsKXrw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01183a506587150539dde2ce
Subject: Re: [PHP-DEV] Simple variable handling.
From: peter.e.lind@gmail.com (Peter Lind)

--089e01183a506587150539dde2ce
Content-Type: text/plain; charset=UTF-8

On 12 August 2016 at 12:52, Lester Caine <lester@lsces.co.uk> wrote:

> On 12/08/16 11:23, Peter Lind wrote:
> > 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.
>
> If you don't set a constraint or other 'intelligent' action then nothing
> changes?
>
>
This is missing the point entirely. The RFC was for a new feature, that you
don't have to use. Not for changing existing ones.



> >>> 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.
>
> We already have a 'strict' mode which enables exceptions on some actions
> or leaves them as errors. I'm simply happy for both to co exist to keep
> others happy.
>
>
Good point.



> >>> 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.
>
> The programming style 'point' is that many sites do simply slap
> htmlspecialchars() around all output and not worry that internally
> suspect data is floating around. On a couple of projects I've been using
> this was the sticking plaster while I prefer to ensure that the
> variables being passed were clean in the first place. In some situations
> sanitising the input may not be practical because of the workflow used
> but THAT is a matter of programming style?
>
>
But other programmers entirely foregoing validation is besides the point.
The point was that conflating validation with escaping/sanitizing is wrong
- and that still applies, even if your chosen method of validation is "I
don't".


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

--089e01183a506587150539dde2ce--