> On 19 Nov 2014, at 21:57, Levi Morrison <le...@php.net> wrote: > >> Since some things might have changed since you last read the RFC, I >> encourage you to read through it again. If there are any questions which >> have not yet been covered on the mailing list, feel free to ask them. > > - 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.
Yes, I suppose that’s a failing of it just now. But to address this: 1) It throws exceptions 2) It is much shorter and more convenient (which is important if we’re to discourage (int), (float) use) 3) to_/try_int() and to_/try_float() don't convert the argument to a string in order to convert > - 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. No, no it would not avoid the issue. We had this before with error return values, which are essentially the same as your proposal. People didn’t like only covering one use case. I didn’t like that. Yes, you can write a wrapper function for a validation function that throws an exception. You also could write one for the error return value function. It’s equally objectionable. Secondly, merely “validating” and not converting means you must then convert after validating. However, the process of validating involves converting it. So you’re doing the same thing twice, essentially, for no conceivable gain. I’ve said it before, I’ll say it again. There’s nothing which is really any better about just having try_int() return TRUE on success rather than the converted value, and not having to_int(). But I’ve had this argument several times now, so I’m not going to have it again on the mailing list. This will be my last word on that suggestion. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
