5 ms·

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 no

by 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.
  - inoop 5y ago
    > That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the old ones. Nobody would use their stuff. But somehow the PHP community thinks this is perfectly normal. It just boggles the mind.
    - mkdirp 5y ago
      > this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve. For the longest PHP was really great with backwards compatibility, refused to address issues in the name of backwards compatibility. So it became the butt of the jokes it is today. As you can imagine, I'm on the other end. Providing backwards compatibility is kept for a relatively long time, I don't think it's unreasonable to break changes with a good system (i.e. major version upgrades). In such cases, I welcome it.
      - inoop 5y ago
        > Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve. Nobody is saying that. The golden rule of API design is do not break your customers. The way you let a language or API evolve is by introducing a new API. For example, instead of changing the semantics of count() you might introduce len() and then try and not fuck it up this time.
    - 9dev 5y ago
      > [...] where each major version upgrade breaks their code? > [...] randomly change their APIs every couple of months [...] This is just FUD. Breaking changes are announced long-term via deprecations, so they don't catch you out of the blue. Every major release of the runtime has three years of support, so nobody "randomly" changes their API every couple of months. I find Google to be a funny example, by the way - picking that one company axing another project or API every other day.

by 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.
- inoop 5y ago
  > That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the old ones. Nobody would use their stuff. But somehow the PHP community thinks this is perfectly normal. It just boggles the mind.
  - mkdirp 5y ago
    > this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve. For the longest PHP was really great with backwards compatibility, refused to address issues in the name of backwards compatibility. So it became the butt of the jokes it is today. As you can imagine, I'm on the other end. Providing backwards compatibility is kept for a relatively long time, I don't think it's unreasonable to break changes with a good system (i.e. major version upgrades). In such cases, I welcome it.
    - inoop 5y ago
      > Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve. Nobody is saying that. The golden rule of API design is do not break your customers. The way you let a language or API evolve is by introducing a new API. For example, instead of changing the semantics of count() you might introduce len() and then try and not fuck it up this time.
  - 9dev 5y ago
    > [...] where each major version upgrade breaks their code? > [...] randomly change their APIs every couple of months [...] This is just FUD. Breaking changes are announced long-term via deprecations, so they don't catch you out of the blue. Every major release of the runtime has three years of support, so nobody "randomly" changes their API every couple of months. I find Google to be a funny example, by the way - picking that one company axing another project or API every other day.