My -1 is pretty much the same as Levi's: On 19 November 2014 13:57, Levi Morrison <le...@php.net> wrote: > - The RFC does not address how this is different from > FILTER_VALIDATE_* from ext/filter. I know there was a mention of this > on the mailing list, but the RFC should say why a tool that already > exists to solve this kind of problem is insufficient, especially when > it is enabled by default.
I'm also somewhat concerned that these functions are conflating two concerns (validation and conversion). > - PHP suffers a lot from function bloat and this RFC provides > multiple functions that do the same thing but differ only in how they > handle errors. A simple validation of "can this be safely cast to an > integer without dataloss?" avoid the issue entirely and would be fewer > functions. +1: the idea of adding two sets of identical functions except for how they signal errors isn't one I like. Derick raised a good point elsethread: this is really tied into how we want to signal errors in PHP 7. If we switch to exceptions, then let's figure out a plan of attack and switch to exceptions everywhere, not just in the odd function here and there. If we don't, then the to_* functions shouldn't be added. > To summarize: I like the idea of having tools that helps us convert > between types in a lossless way, but I don't think this proposal is > what is best for PHP. -1 for me but I hope to see this revisited. I don't know that I'd ever be a strong +1 on this (adding more type conversion matrices to PHP doesn't seem like a good idea to me, whether it's in the language itself or in the standard library, and I feel like we have the validation part of this already in filter and ctype), but if we figured out the error handling situation and had only one set of functions, I could probably grit my teeth and abstain, at least. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
