On Fri, Aug 26, 2022, at 4:00 AM, Michał Marcin Brzuchalski wrote: > A `json_decode()` is a substitute that IMO solves 99% of use cases. > If I'd follow your logic and accept every small addition that handles 1% of > use cases, somebody will raise another RFC > for simplexml_validate_string or yaml_validate and the next > PhpToken::validate.
The heuristic I use is that an API should be "reasonably complete" in one location. Having a half-assed API in C and the rest left to inconsistent and redundant user-space implementations is a terrible API; the same would apply for a user-space library that is half-assed and leaves the rest to "someone else to write." Naturally "reasonably complete" is a somewhat squishy term, which is why it's a heuristic. By that metric, yes, str_starts_with() and friends absolutely belonged in core, because we already have a bunch of string functions and str_starts_with() is by a wide margin the most common usage of strpos(). By the same token, yes, json_validate() makes sense to include in the main API, which means in C. If there's a performance benefit to doing so as well, that makes it an easy sell for me. simplexml_validate_string: I could see the argument there as well, quite frankly. Unless there is already an equivalently capable option in core, which in this case it sounds like there is. yaml_validate: There is no YAML parser that ships with PHP, so no, this wouldn't make sense. If at some point in the future PHP added a C-based YAML extension to the standard distribution, then including a validate function in that would make sense. (Whether we should include a YAML extension in the standard distribution is an entirely separate question.) PHPToken::validate: Again, PHPToken is in core, so why wouldn't we also include a validate for it, especially if it's easy to do and logically belongs in the same "surface area"? Really, the whole "functions don't belong in C" argument is tired. That ship sailed decades ago. PHP has a mixed-implementation life, whether we like it or not. Some APIs and standard lib components are in C, deal. For those that are or make sense to be, they should be robust and self-contained and complete. For those that aren't, they should be kept out as a set, or added "as a set." That's the granularity where we should be talking, not the function level. I'm in favor of this RFC. However, I do agree that it should never throw, period. Only return a boolean. I'm not sure if JSON_INVALID_UTF8_IGNORE makes sense either, frankly. That should get corrected before it goes to a vote. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
