"Peter Lind" wrote in message
news:caeu6nadvbkmqhju0assr5f+ubo9vvryjyvjmr0ihxb8bdmg...@mail.gmail.com...
On 12 August 2016 at 12:13, Lester Caine <les...@lsces.co.uk> wrote:
On 12/08/16 10:42, Peter Lind wrote:
> On 12 August 2016 at 11:25, Lester Caine <les...@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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
