4 ms·

/** * Cast to int, fail if not a valid integer * @throws \UnexpectedValueException * @param mixed $thing * @return int */ function

/** * Cast to int, fail if not a valid integer * @throws \UnexpectedValueException * @param mixed $thing * @return int */ function as_int($thing): int { if (!filter_var($thing, \FILTER_VALIDATE_INT)) throw new \UnexpectedValueException("Value is not an integer."); return (int)$thing; } While, yeah, it'd be nice if there were something like this built in... it's a couple lines of code. If that's your major complaint, I'd be happy to whip up a whole suite of proper functions to cast to primitives while throwing errors on invalid values since it's just swapping FILTER_VALIDATE_INT for the various types.

dvdkon 4y ago
I think this illustrates my problem with PHP well: There are ways to do common tasks properly, but they're often hidden, obscure or basically require creating your own "stdlib extension", as seen here (I only heard about filter_var from this discussion, and I specifically searched for string conversion functions). Your function proves my point: It looks correct, but actually breaks for as_int("0"), since filter_var with FILTER_VALIDATE_INT doesn't acutally validate the int, but parse it, and zero is falsy.
- tored 4y ago
  Above usage of filter_var is wrong, there is no need to cast $thing to int, filter_var already returns the filtered int or false on failure. The correct usage is therefore /** * Cast to int, fail if not a valid integer * @throws \UnexpectedValueException * @param mixed $thing * @return int */ function as_int($thing): int { $int = filter_var($thing, \FILTER_VALIDATE_INT); if ($int === false) { throw new \UnexpectedValueException("Value is not an integer."); } return $int; } Thus the critique against PHP that is lacks a proper integer parsing function is simply not true, filter_var has been part of PHP since 5.2 released in 2006, over 16 years ago. filter_var works as advertised, because I use it almost every time i write PHP and that is to mostly to parse integers but sometimes also for other types. And I don't even wrap it with my own as_int function, using it inline with an simple if-check afterwards is actually cleaner. And if you prefer that filter_var returns null on failure instead of false you can simply add FILTER_NULL_ON_FAILURE as the third argument to filter_var. And this is the recurring thing with PHP critique, vast majority of the time it just in imagination because nobody bothers to look it up. https://www.php.net/manual/en/function.filter-var.php https://www.php.net/manual/en/function.filter-var.php
  - dvdkon 4y ago
    > And this is the recurring thing with PHP critique, vast majority of the time it just in imagination because nobody bothers to look it up. I see this from the other side: Good languages guide programmers toward good solutions. Criticism of the simplest or obvious solution is valid, because the language determines what that solution is. Conversely, arguing that it's possible to write good code is largely meaningless. It doesn't mean that the language is good, just that it isn't completely unfit for purpose. Just look at the number of people who commented about other int parsing methods: Are they bad programmers, because they didn't know to look for filter_var when parsing ints, or is PHP a bad language because something so simple is hard to find a solution for?
    - tored 4y ago
      Why so many failed to answer this questions is probably due to multiple reasons, here are a few 1) Some programmers are just either too lazy or too arrogant to read the manual, thus bad programmers. As a senior programmer that has helped numerous juniors in their work, this is probably one of the most common mistakes I see, they write code without checking how the API works, or they ask me why something isn't working when it can be easily found in the manual. This is not specific to PHP and I have seen this in everything from PHP to C++. 2) PHP is dynamic language, similar to JavaScript, types were not something you historically bothered with, thus parsing to int is not something the community has a large shared knowledge about, similar how it is rare in JavaScript. However with the introduction of primitive type hinting it has become more common to do proper parsing, hopefully PHP programmers will learn eventually. Thus it is a thing with dynamic languages, not specific to PHP. 3) Why can't programmers find the filter_var method in the manual and/or in the standard library? This I considered as valid criticism of PHP, the standard library is not structured because of the C like flat structure and many of the stdlib functions are weirdly named, like filter_var, what is filter to begin with? The solution is to build a better stdlib, not throw out the language. I think the community can build a well designed stdlib if PHP implements operator overloading. The performance issues is no longer valid, PHP 7+ has great performance, thus worrying about losing important cycles is not really true anymore. PHP as a language works well to build good solutions, I have done so in many projects. The critique here evolves around the stdlib, that is not something new.

dvdkon 4y ago

I think this illustrates my problem with PHP well: There are ways to do common tasks properly, but they're often hidden, obscure or basically require creating your own "stdlib extension", as seen here (I only heard about filter_var from this discussion, and I specifically searched for string conversion functions). Your function proves my point: It looks correct, but actually breaks for as_int("0"), since filter_var with FILTER_VALIDATE_INT doesn't acutally validate the int, but parse it, and zero is falsy.

tored 4y ago
Above usage of filter_var is wrong, there is no need to cast $thing to int, filter_var already returns the filtered int or false on failure. The correct usage is therefore /** * Cast to int, fail if not a valid integer * @throws \UnexpectedValueException * @param mixed $thing * @return int */ function as_int($thing): int { $int = filter_var($thing, \FILTER_VALIDATE_INT); if ($int === false) { throw new \UnexpectedValueException("Value is not an integer."); } return $int; } Thus the critique against PHP that is lacks a proper integer parsing function is simply not true, filter_var has been part of PHP since 5.2 released in 2006, over 16 years ago. filter_var works as advertised, because I use it almost every time i write PHP and that is to mostly to parse integers but sometimes also for other types. And I don't even wrap it with my own as_int function, using it inline with an simple if-check afterwards is actually cleaner. And if you prefer that filter_var returns null on failure instead of false you can simply add FILTER_NULL_ON_FAILURE as the third argument to filter_var. And this is the recurring thing with PHP critique, vast majority of the time it just in imagination because nobody bothers to look it up. https://www.php.net/manual/en/function.filter-var.php https://www.php.net/manual/en/function.filter-var.php
- dvdkon 4y ago
  > And this is the recurring thing with PHP critique, vast majority of the time it just in imagination because nobody bothers to look it up. I see this from the other side: Good languages guide programmers toward good solutions. Criticism of the simplest or obvious solution is valid, because the language determines what that solution is. Conversely, arguing that it's possible to write good code is largely meaningless. It doesn't mean that the language is good, just that it isn't completely unfit for purpose. Just look at the number of people who commented about other int parsing methods: Are they bad programmers, because they didn't know to look for filter_var when parsing ints, or is PHP a bad language because something so simple is hard to find a solution for?
  - tored 4y ago
    Why so many failed to answer this questions is probably due to multiple reasons, here are a few 1) Some programmers are just either too lazy or too arrogant to read the manual, thus bad programmers. As a senior programmer that has helped numerous juniors in their work, this is probably one of the most common mistakes I see, they write code without checking how the API works, or they ask me why something isn't working when it can be easily found in the manual. This is not specific to PHP and I have seen this in everything from PHP to C++. 2) PHP is dynamic language, similar to JavaScript, types were not something you historically bothered with, thus parsing to int is not something the community has a large shared knowledge about, similar how it is rare in JavaScript. However with the introduction of primitive type hinting it has become more common to do proper parsing, hopefully PHP programmers will learn eventually. Thus it is a thing with dynamic languages, not specific to PHP. 3) Why can't programmers find the filter_var method in the manual and/or in the standard library? This I considered as valid criticism of PHP, the standard library is not structured because of the C like flat structure and many of the stdlib functions are weirdly named, like filter_var, what is filter to begin with? The solution is to build a better stdlib, not throw out the language. I think the community can build a well designed stdlib if PHP implements operator overloading. The performance issues is no longer valid, PHP 7+ has great performance, thus worrying about losing important cycles is not really true anymore. PHP as a language works well to build good solutions, I have done so in many projects. The critique here evolves around the stdlib, that is not something new.