On 12/08/16 11:23, Peter Lind wrote: > 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.
If you don't set a constraint or other 'intelligent' action then nothing changes? >>> 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. >>> 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? >>> 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. See other post ... to Yasuo -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
