5 ms·

I was curious about this rant since I'm maintaning a number of PHP projects and I haven't had any issues with "count". In the Changelog section of the "count"

I was curious about this rant since I'm maintaning a number of PHP projects and I haven't had any issues with "count". In the Changelog section of the "count" docs at https://www.php.net/manual/en/function.count.php https://www.php.net/manual/en/function.count.php we find: > 7.2.0 - count() will now yield a warning on invalid countable types passed to the value parameter. So in 7.2.0 they started raising a warning in cases where the application was doing a stupid thing (calling count on a non-countable object). Notice that PHP's warnings won't stop execution by default. The expected side-effect here is that you get a warning in the logs and everything keeps working normally. Of course, many development setups halt execution on warnings, but this is a decision that devs make to "force" them to writte better code, not something enforced by PHP itself. > 8.0.0 - count() will now throw TypeError on invalid countable types passed to the value parameter. In the next major version, they turned the warning into an error. Pretty understandable way to improve the language I would say. Of course it would've been better if this was an error from the beginning, but given a mistake was made here, this is definitely the best way to correct it I can think of. I'm sorry it took time for you to fix the legacy apps you've inherited. However, calling this out as an example of bad programming language evolution seems very wrong to me. I for one would LOVE that all languages and libraries in my project's dependency chains where as dilligent as in this example.

throwaway_r211 5y ago
> In the next major version, they turned the warning into an error. Pretty understandable way to improve the language I would say. Breaking changes (at runtime no less) are the worst way to improve any language. They should have created a new count method if they wanted to change behavior in a breaking way. Forcing millions of developers to comb through their code just because some designer doesn't like the way someone else does something is just narcissistic. p.s. Semver isn't worth the shit paper its printed on, it can't even version itself and all it does is give shit developers shit excuses to impose their own naval gazing induced shitstorms on other developers.
- mszcz 5y ago
  I don't think that having two different count()s with different edge-case behavior is the way it should've been improved. If someone used the method incorrectly in the past it's part their fault for writing it incorrectly and part PHP's that it didn't fail (and "fail" is also kind of a stretch since the behavior was described in the docs IIRC).
- cryvate1284 5y ago
  Does PHP say it follows SemVer? I don't know as I don't use it but Python doesn't.
  - deleted 5y ago
    [deleted]
  - johannes1234321 5y ago
    For the most part. However one person's bug is another person's feature and given the huge number of PHP users, where many aren't formally trained developers the ways in which PHP is (ab-)used is manifold. Thus sometimes things slip through as Bugfix, which then annoy people. But over recent times PHP got a lot better (maybe since I'm not involved anymore)
- thinkindie 5y ago
  If you upgrade without proper testing you are the only one to blame. Seems like that blaming PHP is just an excuse for poorly managing language upgrades. PHP has one of the best track records for retrocompatibility, this is really the worst thing you could pick to blame PHP for something.
- EB66 5y ago
  Some of the major criticisms most frequently leveled at PHP relate it's convoluted history, the random ad hoc nature of their built-in functions, the inability to enforce types, overly flexible/dynamic, etc all of which can contribute to, among other things, disorganized code. But then when PHP does something positive to clean things up, we get threads like this. You're damned if you do and damned if you don't. FWIW, how PHP handled `count` was very well done IMHO. The evolution from having `count` throw a warning on non-countable objects to having `count` throw a TypeError has occurred over several years! No one should have been caught off-guard by this very gradual change.
pluc 5y ago
- inoop 5y ago
  > If you don't check what you pass to count() it's really not php's problem, it's your programming. this is a horrible take, language semantics should never change in a backwards-incompatible way. This is API design 101.
  - 9dev 5y ago
    But in fact the semantics did not change within the minor revision boundary. This was an ordinary deprecation process, as it should be. Emitting a warning is not breaking anything!
    - inoop 5y ago
      > did not change within the minor revision boundary I'm confused, are you saying it's fine to change core language semantics as long as it's across major version boundaries? How the hell is that better? No other reasonable language does this.
      - dotancohen 5y ago
        Just wait until you upgrade to Python 3!
        inoop 5y ago
        The Python 3.x change was a disaster, and perfectly illustrates the point I'm making here. PHP should learn from that, instead of trying to repeat it (in slow motion)
      - 9dev 5y ago
        That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. That applies to Go too, for example (talking of reasonable languages...). That PHP ever allowed count()-ing uncountable things is effectively a bug in the standard library. What happened is that a depreciation was put into place, and in the next major version that depreciation was converted to an error. Just how it should have happened. On the one hand, people complain about PHP having weird standard library functions and lots of cruft, on the other they complain once things are changed slowly. I don't get it.

throwaway_r211 5y ago

> In the next major version, they turned the warning into an error. Pretty understandable way to improve the language I would say. Breaking changes (at runtime no less) are the worst way to improve any language. They should have created a new count method if they wanted to change behavior in a breaking way. Forcing millions of developers to comb through their code just because some designer doesn't like the way someone else does something is just narcissistic. p.s. Semver isn't worth the shit paper its printed on, it can't even version itself and all it does is give shit developers shit excuses to impose their own naval gazing induced shitstorms on other developers.

mszcz 5y ago
I don't think that having two different count()s with different edge-case behavior is the way it should've been improved. If someone used the method incorrectly in the past it's part their fault for writing it incorrectly and part PHP's that it didn't fail (and "fail" is also kind of a stretch since the behavior was described in the docs IIRC).
cryvate1284 5y ago
Does PHP say it follows SemVer? I don't know as I don't use it but Python doesn't.
- deleted 5y ago
  [deleted]
- johannes1234321 5y ago
  For the most part. However one person's bug is another person's feature and given the huge number of PHP users, where many aren't formally trained developers the ways in which PHP is (ab-)used is manifold. Thus sometimes things slip through as Bugfix, which then annoy people. But over recent times PHP got a lot better (maybe since I'm not involved anymore)
thinkindie 5y ago
If you upgrade without proper testing you are the only one to blame. Seems like that blaming PHP is just an excuse for poorly managing language upgrades. PHP has one of the best track records for retrocompatibility, this is really the worst thing you could pick to blame PHP for something.
EB66 5y ago
Some of the major criticisms most frequently leveled at PHP relate it's convoluted history, the random ad hoc nature of their built-in functions, the inability to enforce types, overly flexible/dynamic, etc all of which can contribute to, among other things, disorganized code. But then when PHP does something positive to clean things up, we get threads like this. You're damned if you do and damned if you don't. FWIW, how PHP handled `count` was very well done IMHO. The evolution from having `count` throw a warning on non-countable objects to having `count` throw a TypeError has occurred over several years! No one should have been caught off-guard by this very gradual change.

pluc 5y ago

inoop 5y ago
> If you don't check what you pass to count() it's really not php's problem, it's your programming. this is a horrible take, language semantics should never change in a backwards-incompatible way. This is API design 101.
- 9dev 5y ago
  But in fact the semantics did not change within the minor revision boundary. This was an ordinary deprecation process, as it should be. Emitting a warning is not breaking anything!
  - inoop 5y ago
    > did not change within the minor revision boundary I'm confused, are you saying it's fine to change core language semantics as long as it's across major version boundaries? How the hell is that better? No other reasonable language does this.
    - dotancohen 5y ago
      Just wait until you upgrade to Python 3!
      - inoop 5y ago
        The Python 3.x change was a disaster, and perfectly illustrates the point I'm making here. PHP should learn from that, instead of trying to repeat it (in slow motion)
    - 9dev 5y ago
      That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. That applies to Go too, for example (talking of reasonable languages...). That PHP ever allowed count()-ing uncountable things is effectively a bug in the standard library. What happened is that a depreciation was put into place, and in the next major version that depreciation was converted to an error. Just how it should have happened. On the one hand, people complain about PHP having weird standard library functions and lots of cruft, on the other they complain once things are changed slowly. I don't get it.