Yasuo Ohgaki wrote (on 27/01/2014):
I understand this argument. Since we have short release cycle and rather short life for a release, this is short term disadvantage. They may keep using aliases functions also.
At the moment, the short release lifetime is rather more theoretical than proven. PHP 5.3 was released nearly 5 years ago, but some surveys put 5.2 at a 30% share, e.g. http://w3techs.com/technologies/details/pl-php/5/all
What's more, the more radically each version changes, the longer it will take to be adopted, and the more pressure there will be to support older versions in parallel. (I'm talking here about 3rd parties supporting their code, not PHP.net supporting the implementation.)
A long overlap with multiple names for everything has its costs,
and a short overlap with lots of breaking changes also has its cost.
Keeping inconsistent names have its cost also.
A good point.
IMHO, aliases would not affect readability. Users would understand what
word_wrap() and wordwrap()
htmlspecialchar and html_special_chars()
and so on
means.
But they might wonder if there was a difference between them, particularly if the aliases are more distinct (e.g. count() vs sizeof()).
I agree that automatic aliasing would not be good.
String and array function names needs more discussion.
GD function names may be aliased automatically, for example.
We should discuses if we are going to add standard name aliases
to module functions or not, perhaps?
Yes, I think per-module / extension is the way to go - as with the pg_* functions you mentioned earlier.
It can then be proposed that a certain module be converted to OO (as happened with DateTime), another tidied up to have a consistent naming structure, and another left alone until more "interesting" changes are being made to it.
Regards,
--
Rowan Collins
[IMSoP]