Re: Simple variable handling.

"Peter Lind" wrote in message news:CAEU6NAdvBKMqhjU0aSsR5f+uBo9vvRyjYVJmr0ihxb8bDmG3Gg@mail.gmail.com...

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.

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