> -----Original Message----- > From: Lester Caine [mailto:les...@lsces.co.uk] > Sent: Monday, March 02, 2015 11:31 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated > RFC > > Andrea's post highlights the fact that we did try a fix when PHP5 came > out. > What it fails to add is perhaps why the change was reverted? Still today > there > are people pressuring to have it restored? As this thread has shown. At > the > end of the day, this fine tuning of casting action has very little to do > with the > type hinting debate? Now IS the time to discuss the rules but not as part > of > some other RFC? It deserves it's own independent discussion as it SHOULD > apply what ever happens over type hinting.
The whole discussion is presently limited to the area of type hints, and this is unlikely to change for 7.0. I think it's good to think about post 7.0 changes - perhaps bringing the rule-set to other areas of PHP (namely implicit casting), but no, it's not the time to seriously discuss this IMHO. > Thomas's example in my book is where a number of things come into play? > My first thought would be just where is this actually processed and so > where > is it trimmed? Additionally how about '001'? However it does highlight > that a > single 'int' hint is not going to satisfy everybody anyway? The thing > perhaps > to point out here is that we are looking in this case at a source that may > well > be using unicode and wonder if THAT may not be more of a problem here? Whether we have weak, strict, coercive or yellow-red type hints added to PHP, they're absolutely not supposed to satisfy everyone. They're supposed to satisfy most use cases, but not all - for the remaining X percent, you'd have to write a bit of custom code, which is fine (either do away with the hint and do custom validation, or use the hint - but do a bit of preprocessing in the calling code). It's not as if everything we deal with in scalars is going to fit into the various scalar type hint buckets anyway. Functions that accept URLs, or emails, or other types of scalar-but-specifically-formatted data have to be validated with custom code anyway. It's fine for other cases to require a bit of custom validation - as long as the key use cases are covered. I'm obviously biased but I believe that the coercive rules actually cover a lot more ground than the weak+strict sets. In other words, with weak+strict, overall, you're going to have to add custom code in a lot more cases than with the coercive rule set (either because weak is too weak and strict will very frequently be too strict, while coercive provides a rule-set that accepts sensible values and reject non-sensible ones, making it work out of the box in most cases). But even with coercive, it's definitely not a one size fits all solution, and it's not supposed to be either. You still have custom code available to you. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
