Hi Lester, On Tue, Aug 2, 2016 at 2:56 PM, Lester Caine <les...@lsces.co.uk> wrote: > > Once again lots of additional code is being added which only fixes HALF > of the input validation problem. The same as 'strict typing'.
I'm not trying to solve all of input validation issues by this proposal. Large amount of responsibilities are left to programmers. These could be done by callback, regex, multiple filter definitions. If you feel there is missing critical feature, please let me know. I think basic features required by security best practices are provided by this RFC changes. > > All of these extras can simply be eliminated if you address the problem > of adding a set of rules to the basic 'var' that allow proper validation > of each individually ... and *I* include in those rules adding the > correct escaping for that particular variable. Which is EXACTLY what oe > does in the user land libraries that currently fill the gap. > > On one hand we are being pushed to add things like getter and setter and > all that overhead to create proper objects, while this option is back > with handling a raw set of variables as an array? Do you mean validation rule definition? If so, yes. It's an array. Array definition rules could be wrong/broken, e.g. typo, and consequence of a broken definition is severe. So I added definition validation function, validate_check_definition(). (Better name might be preferred "validate" and "check" sounds strange) validate_check_definition() could be called via assert() during development. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
