6 ms·

PHP has a strange identity problem. For a language that most would agree is used due to past popularity, it has a lot of breaking changes. But while syntax gets

• baisq 4y ago
  >there's still no reasonable int parsing function What's wrong with (int)$val ?
  • dvdkon 4y ago
    There's no error handling, (int)"x" === 0.
    • RedShift1 4y ago
      You should use the filter functions for that
    • Y-bar 4y ago
      Why should that be an error? First we are explicitly forcing a string to an integer and then comparing it with type sensitivity to another integer.
      • dvdkon 4y ago
        We could debate that for a long time, but my point was different: There's no sane function in today's PHP that parses ints and handles errors (defaulting to 0 doesn't count).
        • Y-bar 4y ago
          > defaulting to 0 doesn't count Why this arbitrary restriction? A forced cast of a string to integer is always guaranteed to produce an integer.
          • dvdkon 4y ago
            And a forced cast is therefore a bad way to generally parse a user-provided string to int.
            • Y-bar 4y ago
              So why do you insist on using it that way?
              • dvdkon 4y ago
                I don't. I asked for an int parsing function, got (int)$val as a suggestion, so I had to explain why it doesn't fit the bill.
          • samus 4y ago
            And how are we supposed to distinguish that from a legit 0?
            • Y-bar 4y ago
              is_numeric() has been available since forever, and is intended for exactly the thing you appear to want to do. https://www.php.net/manual/en/function.is-numeric.php https://www.php.net/manual/en/function.is-numeric.php
              • deathanatos 4y ago
                At this point you're writing the parser that ships in most language's standard libraries. And, if you naïvely use the suggested function for the purpose you've suggested it for, e.g., like, if(!is_numeric($input)) { error(); } else { return (int)$input; } …you'll parse a lot of strings that still aren't valid integers. (E.g., "2e-2" is "numeric" and would thus parse.)
      • baisq 4y ago
        I think that in that case it should return false instead of 0 so (int)$val === false means that the variable is not a number. Right now I guess that the alternative is using is_numeric and then casting to int if possible.
        • Y-bar 4y ago
          But the forced cast to integer is always guaranteed to result in an integer. So why would it make more sense to explicitly force cast a variable's type to an integer and get a boolean as the functions return value? Edit: > (int)$val === false Would always be false because comparing two types, an integer and boolean would always be false.
    • zerocrates 4y ago
      You can kind of get this to happen in 8 and up: Doing math on a non numeric string is then a catchable TypeError so you can do 'x' + 0 in a try. Doesn't avoid other PHP numeric-string stuff like scientific notation and floats being accepted, though. Passing to a int-typehinted function param in 8.1 gets you closer (will complain about float strings) but is currently just a annoying-to-work-with deprecation notice. Presumably it will eventually also be a TypeError.
    • deleted 4y ago
      [deleted]
• dsego 4y ago
  Lib functions are vertically consistent with the underlying libraries. https://youtu.be/nmD1Q4FsXCc?t=845 https://youtu.be/nmD1Q4FsXCc?t=845
  • dvdkon 4y ago
    Yeah, PHP sometimes pretends it's a C derivative. I think it's a stupid idea most of the time, especially with regard to strings. C string handling isn't anything scripting languages should copy. Besides, PHP now has its own (partly duplicate) class-based stdlib for some things, why not be consistent and "replace" all of the old stdlib?
    • dsego 4y ago
      > C string handling isn't anything scripting languages should copy. Or C-like imports, it's ridiculous tbh, inlcude, inlcude_once, require, require_once. My understanding is that PHP started as a basic templating language, a way to embed c function calls as tags in HTML. In that way it's ingenious, people keep reinventing it with JSX, filesystem routing etc. Right now I'm thinking PHP should've gone the other way. Instead of adopting features to resemble other general purpose languages (things like classes from java and so on) it should've doubled down on web stuff, like JSX - in the sense of having a nice syntax for partials/components, eg <php-component props /> instead of <?php echo php_component(props) ?> and other comfort features, to become a platform.
• qalmakka 4y ago
  Well, they basically took the __looks__ of Perl and bolted on a dynamically typed Java on top of it. I don't think there are languages more different in concepts and values than Perl and Java, and PHP is the result of that unholy mixture. Perl is crazy, but it has a very precise logic behind the madness. Java is boring and predictable. PHP is crazy while being completely random.
  • TedDoesntTalk 4y ago
    This is a good summary of PHP in the past and maybe the present. I think the PHP 10 years from now won’t have the craziness anymore, based on the current trend.
• zerocrates 4y ago
  They've gotten more aggressive lately in wiping away the dusty corners of the language, little-used alternative syntaxes like these,some of the footguns. But nothing even approaching a full reorg/rename of the stdlib. I think the sense is doing something like that would get you into an undesirable "Python 3" type scenario. Instead, the sort of unceasing wave of deprecations leads to some make-work but doesn't seem to cause the same kind of long term resistance to updating.
  • jwommack 4y ago
    They pretty much already had the "Python 3" issue with PHP 6, the unicode PHP
    • zerocrates 4y ago
      Yeah, but it never came out. A bullet dodged.
  • mschuster91 4y ago
    > But nothing even approaching a full reorg/rename of the stdlib. It's been a long tradition in the PHP world to keep the PHP side of a module somewhat consistent with the underlying C API that the module exposes. On the one side, people with a C background immediately find themselves at home in PHP - on the other side, "new" programmers coming from the Java, Go or the matured JS world are confused because of all the inconsistencies.
• chipotle_coyote 4y ago
  > there’s still no reasonable int parsing function! Well, I suppose it depends on how one defines “reasonable”, and perhaps how one defines “parsing” (e.g., what is it you’re trying to do). As a comment elsewhere observed, while (int)$val; will force a non-integer $val to be 0, if what you’re trying to do is determine whether $val is a string literal that represents an integer, you can use filter($val, FILTER_VALIDATE_INT); instead. That will return the integer if it is, and false (actual boolean false) if it isn’t. Is this the best way to do it? Probably not. But I think I’m okay with testing that filter in an if statement rather than wrapping the type casting in a try/catch block. However: > I'm not against change, but PHP devs should decide if they want to make code maintenance easier, or make PHP an actually good language. Right now, it's in a weird in-between state. I'm not a fan of coming across old PHP code and having to make a bunch of small changes to port it to supported PHP. If the dichotomy you pose in the first part is correct, then “coming across old PHP code and having to make small changes” is unavoidable if they’re striving for the latter. Given that they’re clearly not down for making radical changes that break everything everywhere all at once, then it’s going to be in a “weird in-between state” for years, isn’t it?
• tored 4y ago
  stdlib will never change, because it would break every PHP project out there. Many of the previous deprecations as been relatively easy to handle, like switch from each to foreach, or make sure that you don't pass null to stdlib functions, but changing the stdlib itself would instead be a complete nightmare. Remember that many projects out there needs to support multiple PHP versions at the same time, it would be extremely confusing if the stdlib started to do subtle changes between versions and also hard to properly handle and detect. Like if you would swap $needle and $haystack for strpos(), it would be nightmarish to statically detect in an existing code base which is the correct order and quite hard for a human. Introducing aliases is also a bad idea, there already exists aliases in the stdlib and they only add confusion when reading code, that would be true for new aliases as well. Named arguments alleviates the problem with argument order in exchange for more verbosity. What PHP could do is to introduce primitive objects, e.g. $str->substr(...), however that would not guarantee a well designed standard library either, because RFC:s and emails is not a good forum for designing API:s. I think the correct solution is to implement operator overloading and let the community design a standard library/libraries. Because of the massive performance improvements of PHP the standard library is no longer required to be pure C, it can either be implemented in PHP or wrap the existing stdlib.