4 ms·

The problem isn't making mistakes. The problem is not correcting them when you've learned they are a mistake and have had ample opportunity to do so.

by growse 13y ago

fzltrp 13y ago
The opportunity is still there. This kind of mistake is easily fixed: create your own aliases for the functions you'd like to rename, and it's done. If the PHP people are unhappy with them, they could do exactly the same, deprecate and remove the original names through a couple of major releases, and the problem is solved as well. Same solutuon for parameter order (needle, haystack, whatever). Really I don't understand all the fuss around PHP functions names.
- ajuc 13y ago
  > Really I don't understand all the fuss around PHP functions names. You could add aliases to all functions in php in your company, but then you would need to teach these aliases to all new developers. Also every company would have different aliases and people changing jobs would need to relearn everything. So aliases are theorethical solution that nobody use in practice. Changing the standard makes a new common language that you can actually use.
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.

The problem isn't making mistakes. The problem is not correcting them when you've learned they are a mistake and have had ample opportunity to do so.

by growse 13y ago

The problem isn't making mistakes. The problem is not correcting them when you've learned they are a mistake and have had ample opportunity to do so.

fzltrp 13y ago

The opportunity is still there. This kind of mistake is easily fixed: create your own aliases for the functions you'd like to rename, and it's done. If the PHP people are unhappy with them, they could do exactly the same, deprecate and remove the original names through a couple of major releases, and the problem is solved as well. Same solutuon for parameter order (needle, haystack, whatever). Really I don't understand all the fuss around PHP functions names.

ajuc 13y ago
> Really I don't understand all the fuss around PHP functions names. You could add aliases to all functions in php in your company, but then you would need to teach these aliases to all new developers. Also every company would have different aliases and people changing jobs would need to relearn everything. So aliases are theorethical solution that nobody use in practice. Changing the standard makes a new common language that you can actually use.

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.