You want to stick such validation at runtime at any time with variable and throwing \TypeError at any time constraint is broken - wouldn't it cause of throwing much more unexpected exceptions during runtime? Imagine you'll be passing such variable with constraint into some object who operates on it and it should expect \TypeError at any time because you newer know what sort of constraint and optional validation callback is sticked to variable!
I think using constraints annotation style in OO would be much more readable just like using constraint beans in Java https://docs.oracle.com/cd/E19798-01/821-1841/gircz/index.html but that's not the subject of discussion. But that's only my humble opinion. 2016-08-11 3:44 GMT+02:00 Bishop Bettini <bis...@php.net>: > On Wed, Aug 10, 2016 at 4:07 PM, Lester Caine <les...@lsces.co.uk> wrote: > > > People keep complaining that I do not contribute any proposals to > > improve PHP, which to some extent s correct. Except the one thing that I > > keep trying to get a handle on is tidying validating of the basic > > variables that are the heart of PHP. > > > > validate_var_array() is a case in point, since ALL it should do is > > handle an array of simple variables for which we can define REAL > > validation rules rather than just a very restricted 'type' rule. > > Massaging the way the content of a variable is presented is another part > > of the basic functions of handling a variable, and simply providing an > > escape option which can be set as part of the variable rules set > > eliminates the need for 'New operator (short tag) for context-dependent > > escaping' and similar tangential matters. If we have a set of rules > > wrapping a variable then everything else just follows on, and the SQL > > domain model allows a group of variables to take an identical se of > rules. > > > > These are the sorts of things any decent user world library can and does > > provide, but if the clock was rolled back prior to all the trouble > > created by 'strict typing' and we started again with a more well defined > > simple variable I'm sure that much of the conflict could have been > > resolved by allowing full validation checks to control an error or > > exception depending on the 'style' of PHP a programmer prefers. > > > > If a function is going to return a variable and that variable has under > > the hood a set of validation rules, then one can return an error if the > > result is faulty. Or even allow a NULL return if a valid answer is not > > available ... if that is the style of programming one prefers. > > Exceptions handle unmanaged errors, while proper program flow handles > > managed ones! > > > > Wrap these intelligent variables inside a class and one can create more > > powerful objects but ones which still use all the basic functionality. > > Similarly an array of them can be asked to provide a simple 'yes/no' if > > all of the variables pass their validation check, or an array of > > elements which need processing. > > > > Do you mean attaching a functional validator to a variable, something like > this hypothetical code? (Note the 3rd argument to settype): > > // $_POST['age'] = 27; > // $_POST['name'] = 'Sugah Pop'; > > try { > settype($_POST['age'], 'int', 'is_int'); > settype($_POST['name'], 'string', function ($name) { return > strlen($name) < 255; }); > } catch (\TypeError $er) { > die($er->getMessage()); > } > > // ... Later: > > $_POST['name'] = str_repeat('a', 1024); > // Throws \TypeError: "Invalid value set into variable in demo.php on line > 14" > > Or same idea, but used as "smarter" formal argument validators: > > function do_something($age, $name) { > settype($age, 'int', 'is_int'); > settype($name, 'string', function ($name) { return strlen($name) < 255; > }); > // $age and $name now have persistent validator rules attached to them > // write operations onto the variable will assert the truth of the > // validator before assigning. Obviously, there is a run-time cost. > } > -- pozdrawiam -- Michał Brzuchalski
