Lester Caine wrote on 29/04/2016 17:50:
On 29/04/16 16:42, Rowan Collins wrote:function foo($a) { if ( $a < 42 ) { throw new Exception; } // Must not reach The Answer ... }vs <<test($a < 42)>> // Must not reach The Answer function foo($a) { ... }The first version is my current code base, although it's unlikely to throw an exception, more likely to have already validated the data before using it so the check is redundant as it is already in the code to handle the problem data. But in the second example just where does the error redirect traffic? At least with in-line checks you control flow ...
A good question. As such, the annotation doesn't execute any code in the current proposal, it just allows tools to inspect it, so the answer is "anywhere the tool manages to inject the assertion code", I guess.
but just how do you add a range? Does that need different 'test' elements?
<<test>> is just an example. It might be <<Validate\Range(0, 42)>> or <<ConstrainType\Int(['min'=>0, 'max'=>42])>> or whatever you / the library author wanted it to be. None of this is going to be baked into the language.
My main target here is to add a reliable mechanism to allow every variable to have it's own validation attributes. The only current route is as php-annotations nicely provided and which dovetails nicely into the existing documentation process.
Indeed, the fact that you can add the attributes in advance is a nice feature of the annotations-in-docblock syntax. However, the disadvantages of that syntax have been discussed elsewhere. Like many things in life, it's a tradeoff.
I've no problem with an alternate annotation method ... as long as in PHP7 it is optional ...
Absolutely. Nobody is going to force you to use this syntax, unless you want to use some library whose author is really keen on it and doesn't provide any other method of doing something.
but I don't think this 'in-line' approach is ACTUALLY the right long term solution to data validation.
You said just now that adding the validation to the docblocks does appeal to you. At the end of the day, this is just another syntax for doing the same thing; but a more well-defined, easier-to-parse syntax, with no baggage of existing usage which it has to be compatible with.
If it's not the right tool for your use case, that's fine too; maybe it's the right tool for someone else's use case, though.
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
