5 ms·

Sometimes I wonder how important backward compatibility is. A lot of <=PHP4 libs wont run on a modern server so there are already compatibility issues. Maybe P

by ohwp 13y ago

Sometimes I wonder how important backward compatibility is. A lot of <=PHP4 libs wont run on a modern server so there are already compatibility issues. Maybe PHP6 could be a complete cleanup. And maybe the focus shouldn't be on backward compatibility but on running <6 and 6 side by side.

dnzm 13y ago
Agreed. Backward compatibility is nice, but you have to draw the line somewhere.
frik 13y ago
They better keep the backward compatibility, or you face the fiasco of Python 2 vs 3. The way that PHP deprecate API functions slowly over a period of time is prefered.
- ohwp 13y ago
  Well I was thinking about Python when I wrote my comment :) One of the problems with Python is that they almost encouraged writing code in 2 and porting it to 3. Also: Python 3 is almost a complete different language. It would be the same when PHP6 would use a + as string concatenation. Such changes would turn it into a complete different language.
  - frik 13y ago
    Hopefully, PHP.net community won't go this route. The C-like syntax and the more or less stable code base (compatibility) are the main advantages over Python, Ruby, Go.
  - Pacabel 13y ago
    Have you ever actually used Python 2 and Python 3? Python 3 is not "almost a complete different language", as you put it. Somebody who has used both will notice that Python 3 is syntactically and semantically almost identical to Python 2 in most respects. The main differences are in terms of removing redundancy, removing outdated features and functionality, increasing consistency, vastly improved Unicode support, and standard library improvements. A developer with Python 2 experience should be able to pick up Python 3 in about 30 minutes, at the most. That's not what we'd expect were Python 3 "almost a complete different language".
- nikcub 13y ago
  the migration from v4 to v5 went ok, considering there was a large blog campaign against end-of-lifing php v4 (I remember Matt Mullenweg, amongst many other bloggers and hosting companies, had the badge in their blog sidebars) and there was a lot of resistance to it. The big thing with PHPv5 was not just having to migrate code, but even at the time v4 was no longer supported and v5 had been out for years in benchmarks v4 was still 20-30% faster then v5. v5 to v6 could be a similarly smaller scale migration. The number of backwards incompatible changes in 4 to 5 wasn't long: http://www.php.net/manual/en/migration5.incompatible.php http://www.php.net/manual/en/migration5.incompatible.php Slashdot thread from the time with some details on the resistance: http://beta.slashdot.org/story/87591 http://beta.slashdot.org/story/87591 Migrating from v3 to v4 was also a backwards incompatible leap: http://www.physnet.uni-hamburg.de/physnet/php/migration4.html http://www.physnet.uni-hamburg.de/physnet/php/migration4.htm... So the PHP project has pulled it off twice already, perhaps they don't get enough credit for that.
- Pacabel 13y ago
  I don't see how the Python 2 to Python 3 transition has been a "fiasco". It may not have been the fastest transition, but that really doesn't matter in practice. Individuals and organizations with extensive Python 2.x software systems have been able to continue using those with no problems. Development has been able to continue on Python 3.x without needing to worry about backward compatibility with Python 2.x. It is a cleaner language, in many ways. Over time, we have indeed seen libraries, frameworks and users migrate from 2.x to 3.x as it benefits them. It's not something that's forced on them, causing disruption and anger. And so we've gradually seen Python 3.x starting to become more and more adopted, while Python 2.x slowly fades away. It's a non-disruptive, steady transition. If you want to talk about a real fiasco, Perl 6 is a much better example. Having no truly usable implementation after nearly 15 years, and thus basically no adoption, does qualify as a disaster in every sense.
  - rjbond3rd 13y ago
    True, Perl 6 is an amazing fiasco! Every bad thing in software has happened, so it's the world's most sensational counter-example! Stay away! Hide your kids! P.S. But from close-up, it's the think-tank and test-bed of potential Perl 5 upgrades. Even if Perl 6 never ships, it's contributed tons of shipping code for Perl 5. Yes, it's hard to understand that from a distance, and it's not a PR dream, but oh well.
    - chromatic 13y ago
      But from close-up, it's the think-tank and test-bed of potential Perl 5 upgrades. I question this claim. Perhaps it's true of some syntactic features (`say` comes to mind as do some proposals for function signatures), but the semantics rarely translate over well (consider smartmatch). If you squint and tilt your head you can claim that Moose is an example of a feature designed in one language and implemented in another, but Moose is more an exercise in language/feature syncretism than it is porting something complete in implementation or design to Perl 5.
Udo 13y ago
A core API cleanup would be nice, but I think they have to worry about the transition. There would have to be a period when both APIs work so projects can transition gracefully and servers can host code written for both. An abrupt change would probably hurt the new version, the old, or most likely both. If we could get on the same page what the new naming conventions and parameter orders are supposed to be, we could start to use a shim file on 5.x to prepare for 6.x.
thaJeztah 13y ago
I agree completely, maybe PHP should use the same approach as the jQuery migration-plugin, which; - Logs usage of old or (to-be) deprecated functionality - Provides deprecated functionality so that existing code doesn't break This way; - The PHP API can finally be cleaned up (please, also move those old functions to a separate section in the documentation) - Older code can still run, but enabling the 'migration/compatibility' plug-in (should be possible to enable/disable this per site, not for the whole server at once) - Developers are informed that their code uses deprecated functionality, giving them time to migrate code. Although this approach is comparable to the E_STRICT flag, it is going one step further, in that the deprecated functions are actually removed from the core, and must be manually enabled/added via an optional plugin. Reorganising the documentation is an important part of this; cleaning up the old stuff will make PHP less confusing (should I use 'implode()' or 'join()'?), and will silently guide new developers away from the old stuff. On a final note; if this approach allows hosting-providers to upgrade PHP without breaking their client's code, adoption rate of newer PHP versions will probably be faster as well!

by ohwp 13y ago

dnzm 13y ago

Agreed. Backward compatibility is nice, but you have to draw the line somewhere.

frik 13y ago

They better keep the backward compatibility, or you face the fiasco of Python 2 vs 3. The way that PHP deprecate API functions slowly over a period of time is prefered.

ohwp 13y ago
Well I was thinking about Python when I wrote my comment :) One of the problems with Python is that they almost encouraged writing code in 2 and porting it to 3. Also: Python 3 is almost a complete different language. It would be the same when PHP6 would use a + as string concatenation. Such changes would turn it into a complete different language.
- frik 13y ago
  Hopefully, PHP.net community won't go this route. The C-like syntax and the more or less stable code base (compatibility) are the main advantages over Python, Ruby, Go.
- Pacabel 13y ago
  Have you ever actually used Python 2 and Python 3? Python 3 is not "almost a complete different language", as you put it. Somebody who has used both will notice that Python 3 is syntactically and semantically almost identical to Python 2 in most respects. The main differences are in terms of removing redundancy, removing outdated features and functionality, increasing consistency, vastly improved Unicode support, and standard library improvements. A developer with Python 2 experience should be able to pick up Python 3 in about 30 minutes, at the most. That's not what we'd expect were Python 3 "almost a complete different language".
nikcub 13y ago
the migration from v4 to v5 went ok, considering there was a large blog campaign against end-of-lifing php v4 (I remember Matt Mullenweg, amongst many other bloggers and hosting companies, had the badge in their blog sidebars) and there was a lot of resistance to it. The big thing with PHPv5 was not just having to migrate code, but even at the time v4 was no longer supported and v5 had been out for years in benchmarks v4 was still 20-30% faster then v5. v5 to v6 could be a similarly smaller scale migration. The number of backwards incompatible changes in 4 to 5 wasn't long: http://www.php.net/manual/en/migration5.incompatible.php http://www.php.net/manual/en/migration5.incompatible.php Slashdot thread from the time with some details on the resistance: http://beta.slashdot.org/story/87591 http://beta.slashdot.org/story/87591 Migrating from v3 to v4 was also a backwards incompatible leap: http://www.physnet.uni-hamburg.de/physnet/php/migration4.html http://www.physnet.uni-hamburg.de/physnet/php/migration4.htm... So the PHP project has pulled it off twice already, perhaps they don't get enough credit for that.
Pacabel 13y ago
I don't see how the Python 2 to Python 3 transition has been a "fiasco". It may not have been the fastest transition, but that really doesn't matter in practice. Individuals and organizations with extensive Python 2.x software systems have been able to continue using those with no problems. Development has been able to continue on Python 3.x without needing to worry about backward compatibility with Python 2.x. It is a cleaner language, in many ways. Over time, we have indeed seen libraries, frameworks and users migrate from 2.x to 3.x as it benefits them. It's not something that's forced on them, causing disruption and anger. And so we've gradually seen Python 3.x starting to become more and more adopted, while Python 2.x slowly fades away. It's a non-disruptive, steady transition. If you want to talk about a real fiasco, Perl 6 is a much better example. Having no truly usable implementation after nearly 15 years, and thus basically no adoption, does qualify as a disaster in every sense.
- rjbond3rd 13y ago
  True, Perl 6 is an amazing fiasco! Every bad thing in software has happened, so it's the world's most sensational counter-example! Stay away! Hide your kids! P.S. But from close-up, it's the think-tank and test-bed of potential Perl 5 upgrades. Even if Perl 6 never ships, it's contributed tons of shipping code for Perl 5. Yes, it's hard to understand that from a distance, and it's not a PR dream, but oh well.
  - chromatic 13y ago
    But from close-up, it's the think-tank and test-bed of potential Perl 5 upgrades. I question this claim. Perhaps it's true of some syntactic features (`say` comes to mind as do some proposals for function signatures), but the semantics rarely translate over well (consider smartmatch). If you squint and tilt your head you can claim that Moose is an example of a feature designed in one language and implemented in another, but Moose is more an exercise in language/feature syncretism than it is porting something complete in implementation or design to Perl 5.

Udo 13y ago

A core API cleanup would be nice, but I think they have to worry about the transition. There would have to be a period when both APIs work so projects can transition gracefully and servers can host code written for both. An abrupt change would probably hurt the new version, the old, or most likely both. If we could get on the same page what the new naming conventions and parameter orders are supposed to be, we could start to use a shim file on 5.x to prepare for 6.x.

thaJeztah 13y ago

I agree completely, maybe PHP should use the same approach as the jQuery migration-plugin, which; - Logs usage of old or (to-be) deprecated functionality - Provides deprecated functionality so that existing code doesn't break This way; - The PHP API can finally be cleaned up (please, also move those old functions to a separate section in the documentation) - Older code can still run, but enabling the 'migration/compatibility' plug-in (should be possible to enable/disable this per site, not for the whole server at once) - Developers are informed that their code uses deprecated functionality, giving them time to migrate code. Although this approach is comparable to the E_STRICT flag, it is going one step further, in that the deprecated functions are actually removed from the core, and must be manually enabled/added via an optional plugin. Reorganising the documentation is an important part of this; cleaning up the old stuff will make PHP less confusing (should I use 'implode()' or 'join()'?), and will silently guide new developers away from the old stuff. On a final note; if this approach allows hosting-providers to upgrade PHP without breaking their client's code, adoption rate of newer PHP versions will probably be faster as well!