Disclaimer: I'm a big fan of PHP, not because I like the language, but because I like the pragmatic approach.
I think that's foolish. Redesigning a language is making a new language -- and there are lots of other new languages to choose from. What features of PHP would you want to keep that aren't possible in other languages?
Radically changing the language also leads to heavily splitting the community like with PHP4/PHP5 or Perl5/Perl6 or Python2/Python3 and nobody wants that. Backwards compatibility doesn't have to be fully maintained but it does have to be respected.
The biggest issue right now with PHP is that there isn't a clear direction on where to go. Nobody wants to "fix" some of the old problems because the gains don't seem to outweigh the costs.
That's what PHP is missing: expert mode. As it stands now it's very difficult to turn off all the traps, so experienced programmers are forced to switch to other languages. Compare this to Perl, where it has silly behavior by default, but you can turn it off with "use strict" at the top of the file.
However, I agree, all languages should have the ability to turn off the backwards compatibility crud with some kind of statement. In PHP, it would be great to do that at the namespace level -- allowing different libraries to operate at different levels of support/strictness in the same project.
But I wonder if maybe you're blind to the ways your PHP is different. Dozens of modules and hundreds of functions come directly with the language core. And very very esoteric stuff. Why does my programming language have a function to tell me specifically what day Easter is? Whaa? Why do I have to recompile my programming language to install new libraries? (PCNTL, for example).
If PHP is a salad bar, Python (for example) is prix fixe.
wget http://www.php.net/get/php-5.3.16.tar.gz/from/us2.php.net/mirror -O php-5.3.16.tar.gz
tar zxvf php-5.3.16.tar.gz
cd php-5.3.16/ext/pcntl
phpize
./configure
make
sudo make install
Of course with non-bundled extensions from pecl or github you can skip the tarball step.
pip install package_name or gem install package_name
not to mention, with bundler and virtualenv you can easily, easily keep multiple versions of different packages for different projects without any juggling and hacking your way through.
When I have time for side projects again, I'm going to make this happen for CoffeeScript running under v8cgi or node. The code for the "HTML by default" is trivial enough that I could write it in fifteen minutes. The code for the global namespace (I'd prefer a short namespace actually) stuff is a bit more tedious, and the parts with making it run a server under node and automatically parse and cache the files are the boring details that I might get stuck on and cause the project to languish. Ideally, I'd want to make it flexible regarding frontends, so that if you could get it running in any environment that accepted JS code and could wrap the built in module behavior.
The frustrating thing is that until we see more widespread support for server-side JS on reasonably cheap hosts, or at least some well-implemented JS transpilers/interpreters for commonly installed languages like Python and PHP, making this work for Joe Everydev is going to be virtually impossible.
I'd be interested in doing something similar for Python (mod_python supports something close in PSP, but nobody seems to use mod_python anymore), but while I'm capable with Python, I've never really been interested in learning the ins and outs of the "Pythonic" style, and that makes me reluctant to put any code out where the Python community can see it.
I think the way PHP is evolving is how it has always evolved. No one's thinking 5 years into the future. But I argue that they don't have to. PHP doesn't win on it's big design advantage, it wins on all of the small parts that it haphazardly releases (I don't mean that in a bad way).
This "redesign" thing you talk about would never happen. Or it happened already dozens of times, if you want. It's just called other languages, not PHP. PHP is something that it is, and it develops and gets better, but if you think the whole premise is wrong - fine, there are tons of other approaches around. That doesn't mean every topic on PHP should be accompanied by good old "yeah, that's nice, but you have to redesign it". What's the point of it?
It seems like one way for them to fix a lot of the old stuff while maintaining backwards compatibility would be to add new string and array (and dictionary?) classes with sensibly-defined interfaces. I imagine there are a fair number of less-obvious issues around that that make not as easy as that sounds, though.
All of PHP4's syntax is still valid in PHP5 even if it does raise a deprecated notice.
The only real thing that broke in the upgrade is if you had a LOC that was expecting an object to be passed by value. Theoretically possible but practically very very rare.
And of course config settings like register globals being changed, but that's just that: a config change.
PHP5 changed the semantics of objects entirely. Before they were value types.
Still, yes, not enough has changed IMO.
You're implying it was an implementation detail. They fundamentally changed how objects worked, the semantics, that made it completely impossible to move any of my PHP4 code over in a reasonable way.
It is possible to make code, that uses objects, work in both PHP4 and PHP5 but you have to restrict yourself to a subset of both versions.
None of the PHP4 frameworks moved over to PHP5 without a lot of re-writing.
My code simply assumed value assignment semantics and changing that everywhere was just too much work. At this moment, I still have sites running PHP4.
Were you passing around objects and mutating them while expecting the existing object to be unchanged? For example:
$o = new MyObject()
$o->important_data = 'clean';
function foo($give_me_o) {
$o->important_data = 'dirty';
}
foo($o);
echo $o; // Need this to say "clean"
Frameworks chose to upgrade because you get MUCH better memory management and cleaner syntax from PHP5. But many, many people run PHP4 code in a PHP5 runtime. It works just fine. Because that example I used above -- while it is totally possible you have code like that, that's in practice pretty rare.
The potential for subtle bugs with this change is massive.
Your example is very simple. I've got objects with other objects as properties (composition), collections of objects, hierarchies of object references, as well as methods that take objects by reference or by value. Not using references everywhere is so much easier in PHP4 that whenever possible, I did just that.