On 20 November 2014 18:06, Andrea Faulds <a...@ajf.me> wrote: > >> On 21 Nov 2014, at 00:45, Adam Harvey <ahar...@php.net> wrote: >> >> 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. > > While that was true when Levi said it, the RFC *does* address this now.
That's fair — I read the RFC again when it first came up for vote, in my defence, but wanted some time to think about it. I should have re-read it before actually voting. Sorry about that. The clunkiness of the filter API is a valid point, although I don't think unconditionally adding a bunch of unnamespaced functions — which can be implemented in userspace just fine — is the right way of dealing with it. (I've snipped your rationale and example. Thanks for writing it — I don't necessarily agree with it, but it's a good explanation of your thinking, and probably something that would have helped the RFC.) >>> - 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. > > The problem is that it’s the least bad of the available options. I disagree. To my mind, the best option right now (barring the status quo, which realistically I'd prefer) would be the try_* functions only. They line up with how ext/standard (and pretty much all of PHP other than a smattering of OO functions and SPL) signal errors, and avoid duplication. I don't really fancy explaining the difference between to_* and try_* in ##php to a new developer. PHP may be a mishmash of undesigned APIs in places, but that doesn't mean we should dump fuel on the fire by adding two parallel APIs that are named obscurely and differ only in how they signal errors. >> 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. > > This isn’t a switch, though, these are new additions. We already have > exceptions in a few places in core, and there’s nothing wrong with new > additions using exceptions if and when appropriate. The question is over how > to deal with legacy code. There's no function in php-src today that throws an exception outside of an OO context. (Indeed, if you go through the various classes and methods in php-src, I suspect even _in_ an OO context the majority of errors are signalled via return values or PHP errors.) Right now, the standard for appropriateness when adding an exception is pretty much "is this an error generated in an OO context"? This clearly isn't. To be clear: if a way could be designed to do it without shredding BC, I'd be ecstatic if we deprecated our current error handling system entirely in favour of exceptions in PHP 7. But that's not the standard right now, and an unrelated RFC like this isn't the place to make that decision. > In this specific case, I suppose the other option would have been to throw an > E_RECOVERABLE_ERROR. But exceptions can be handled easier, and so I don’t see > a particular reason why it shouldn’t throw an exception. Why would you throw an E_RECOVERABLE_ERROR? The error's been signalled: the function returned NULL, rather than an int/float/string. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
