Not a voter, but I don't really see the usefulness of this in core either.
Sent from my iPhone > On 21 Nov 2014, at 11:45 am, Adam Harvey <ahar...@php.net> wrote: > > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
