5 ms·

Very true; I would be disappointed to discover that PHP is still using the same hashing function. However, changing the function names (especially some of the

by choult 13y ago

Very true; I would be disappointed to discover that PHP is still using the same hashing function. However, changing the function names (especially some of the core ones) is fraught with backwards-compatibility issues - PHP code written 15 years ago should, for the most part, still work, and not enough hosts out there run with the right error reporting to point out deprecation warnings, so you would probably end up with a lot of PHP sites with code silently failing when a host upgraded.

deleted 13y ago
[deleted]
laumars 13y ago
I completely disagree. As a language matures, features need to be depreciated as newer / better features are implemented. It's actually quite common for languages to do this. In fact PHP HAS depreciated functions over it's life, so 15 year old code might not run on modern web servers anyway. Yet we still have the same function names where they should have been renamed.
- choult 13y ago
  I'm all for standardizing core function names and deprecating outmoded items, but I was merely pointing out the problems inherent in doing so - there are pros and cons to all decisions, and a great deal are complicated greatly once they're out in the wild for a long time.
  - laumars 13y ago
    I think the latest PHP APIs are the least of your problems if you're running sites with code that hasn't been touched in 15 years: * new security threats that have been discovered in that time which needed to be coded against (In the last 15 years, a lot has changed with the approach we have to building secure sites). * newer web standards and browsers - thus compatibility on the client side might now be an issue. * different computing paradigms (we use touch interfaces where hover-over menus wouldn't function. There's a massive range of different client side screen resolutions and aspect ratios these days too). * different methods of sharing content (for some types of sites, supporting OpenGraph and Twitter Cards is pretty important if you depend on your content getting exposure from "word of mouth"). * different user expectations (a 15 year old site is unlikely to look any good compared their modern counterparts. While that might not matter for some sites, if you're trying to generate traffic from the average layman, then they might be put off and prefer a site which is more aesthetically pleasing). So if someone is trying to port 15 year old PHP code to a new server, then I'd expect they'd want / need to do a sizeable amount of rewriting anyway - regardless of API compatibility. In this instance, API compatibility is the least of their worries as you can at least just use the 'find/replace' tool in your text editor to fix renamed APIs, where as fixing the other issues (eg switching from the older method of dropping variables into an SQL string, to the current preferred method of parametrized SQL which negates the risk of SQL injection attacks) will take much longer.
- sudomal 13y ago
  One thing I like a lot about PHP is its version stability, it has changed somewhat over time, but not to the point where it breaks important features. I have seen many a framework and language (the sort that you might see hyped on this website) that make drastic changes and only their most ardent fans stick with the new version. It's often an opportunity to switch to the next big thing.
  - laumars 13y ago
    I'm not asking for PHP to break it's compatibility over night, but it's fairly reasonable for a language to depreciate a function over several major releases which might span a few years. ie version 5.6 will raise a warning when some_function is called, saying that some_function will be depreciated in future versions of PHP. So you have both the old and new functions running in parallel for a while. Then a couple of major versions later, you drop support for the older function name. As I said before, PHP has already been doing just this for some stuff for a while now, so it's not an alien concept to PHP developers.

by choult 13y ago

deleted 13y ago

[deleted]

laumars 13y ago

I completely disagree. As a language matures, features need to be depreciated as newer / better features are implemented. It's actually quite common for languages to do this. In fact PHP HAS depreciated functions over it's life, so 15 year old code might not run on modern web servers anyway. Yet we still have the same function names where they should have been renamed.

choult 13y ago
I'm all for standardizing core function names and deprecating outmoded items, but I was merely pointing out the problems inherent in doing so - there are pros and cons to all decisions, and a great deal are complicated greatly once they're out in the wild for a long time.
- laumars 13y ago
  I think the latest PHP APIs are the least of your problems if you're running sites with code that hasn't been touched in 15 years: * new security threats that have been discovered in that time which needed to be coded against (In the last 15 years, a lot has changed with the approach we have to building secure sites). * newer web standards and browsers - thus compatibility on the client side might now be an issue. * different computing paradigms (we use touch interfaces where hover-over menus wouldn't function. There's a massive range of different client side screen resolutions and aspect ratios these days too). * different methods of sharing content (for some types of sites, supporting OpenGraph and Twitter Cards is pretty important if you depend on your content getting exposure from "word of mouth"). * different user expectations (a 15 year old site is unlikely to look any good compared their modern counterparts. While that might not matter for some sites, if you're trying to generate traffic from the average layman, then they might be put off and prefer a site which is more aesthetically pleasing). So if someone is trying to port 15 year old PHP code to a new server, then I'd expect they'd want / need to do a sizeable amount of rewriting anyway - regardless of API compatibility. In this instance, API compatibility is the least of their worries as you can at least just use the 'find/replace' tool in your text editor to fix renamed APIs, where as fixing the other issues (eg switching from the older method of dropping variables into an SQL string, to the current preferred method of parametrized SQL which negates the risk of SQL injection attacks) will take much longer.
sudomal 13y ago
One thing I like a lot about PHP is its version stability, it has changed somewhat over time, but not to the point where it breaks important features. I have seen many a framework and language (the sort that you might see hyped on this website) that make drastic changes and only their most ardent fans stick with the new version. It's often an opportunity to switch to the next big thing.
- laumars 13y ago
  I'm not asking for PHP to break it's compatibility over night, but it's fairly reasonable for a language to depreciate a function over several major releases which might span a few years. ie version 5.6 will raise a warning when some_function is called, saying that some_function will be depreciated in future versions of PHP. So you have both the old and new functions running in parallel for a while. Then a couple of major versions later, you drop support for the older function name. As I said before, PHP has already been doing just this for some stuff for a while now, so it's not an alien concept to PHP developers.