Not sure where the docs are though (if there even are any yet).
Will possibly post later with any interesting, early findings
Moderator: General Moderators
Its not a binary "yes/no" question. It is definitely a quantitative question, and the answer is that the quantity of things changed (that can break scripts) was low.Gambler wrote:PHP 5 changed enough things to break some scripts.
For what reason? I would argue the opposite - that if an application isn't updated once a year, its not an important app.Gambler wrote:Whether it is possible to fix them is not important.
The first part is correct, the second part is not. They are eliminating some legacy items (such as the use of magic_quotes), which makes it not forward compatible. However, they do so to improve best practice - the new features (replacing the old) improves the best practices in the language.Gambler wrote:The point is that total subset of version-portable and good-practice features decreases with each new release.
Actually, its becoming more consistent - for the version at hand. If you consider the language as living (which I posit is a good thing), then the current version (PHP5) is more consistent than PHP4 was, and PHP6 will in turn be more consistent than PHP5 is.Gambler wrote:As an additional bonus, syntax of each new language version becomes more and more incosistent. (Good example is define() and const.)
It depends on your definition of drop-in replacement. If you make the requirement 100% compatibility, yes, you are right, its not. If you make the requirement 100% compatibility for scripts that are up to date, then no, you are wrong, it is a drop-in replacement.Gambler wrote:PHP 5 is not a drop-in replacement for PHP 4. That is why hosting companies are so unwilling to upgrade.
They are rarely rejecting features on that ground. If you read the paris notes, there was only two items that they rejected on that ground, and that wasn't the main reason they rejected them!Gambler wrote:This leads to the situation where many possible features and fixes are rejected, because "it will break backward compatibility." Resulting language is "kind of" new and "kind of" compatible.
Let me rephrase that. The point is that the total subset of features that are both version-portable and good practice decreases with each new release.The first part is correct, the second part is not.
Because I was speaking about motion of the language as a whole. And my point is that the total subset of features that are... Well, I hope you get the meaning.For what reason?Whether it is possible to fix them is not important.
I'm not suggesting to maintain 100% compatibility at all costs. I'm saying that current "incremental upgrade" tactics is a half-way solution. It not perfect for the people who want incompatible new features, and neither it it the best for people who want compatibility without headaches. There are other solutions, which would be more desirable for both parties. One of them is to isolate different versions. For example, .php files would be executed by PHP 4, while .php5 files would be used by PHP 5. My provider currently uses such setup as a "replacement" for real 4 to 5 upgrade. However, if we assume that it is an okay solution, than the nature of many compatibility struggles, which slow down the development of the language, becomes unclear. Plus, I did not expect PHP 6 to be released so soon, and I hoped that developers would somehow solve compatibility problem in sixth version.Choosing to *never* eliminate legacy would result in Perl.
If scripts have to be somehow changed to be up-to-date, than it is not a drop-in replacement. This has nothing to do with my definitions, as long as you use the term "drop-in replacement" the way people usually use it.PHP 5 is not a drop-in replacement for PHP 4. That is why hosting companies are so unwilling to upgrade.It depends on your definition of drop-in replacement. If you make the requirement 100% compatibility, yes, you are right, its not. If you make the requirement 100% compatibility for scripts that are up to date, then no, you are wrong, it is a drop-in replacement.
Examples?Actually, its becoming more consistent
True. That's because they usually do not consider features that would seriously break BC in the first place.They are rarely rejecting features on that ground.
This is one of the 10 most abused "arguments" on the web. It simply questions the right of a person to say certain things, rather than showing that person is erroneous in his conclusions. It is neither valid, nor exclusive for open source, and can be used to defend pretty much anything without providing any reasoning. In fact, I can use the same pattern to defend my posts. Here it goes.As with so many opensource projects, if you think you can do better, step up. Otherwise, give some appreciation to the people working hard to make a fairly solid product - at least solid enough that you use it on a regular basis. You are always welcome to use something else.
There is no arbitrary rule for what is important or not, so saying such a rule is misguidance.Roja wrote:For what reason? I would argue the opposite - that if an application isn't updated once a year, its not an important app.
I thought everyone knew that?Jcart wrote:wow.Earlier this day Rasmus posted a couple of benchmarks on the php.internals ML showing that php4.4 was faster than php5.1..
There was a touch of sarcasm. I was trying to highlight the fact that Gamblers stance that "requring any change is bad" was too binary and unreasonable.Jenk wrote:There is no arbitrary rule for what is important or not, so saying such a rule is misguidance.Roja wrote:For what reason? I would argue the opposite - that if an application isn't updated once a year, its not an important app.
That does help clarify a bit. Can't disagree there, but then again, I don't put the same value on that combination that you do. I'm more interested in good practice in a given release, than I am about that practice being good across multiple releases.Gambler wrote:Let me rephrase that. The point is that the total subset of features that are both version-portable and good practice decreases with each new release.
I don't. As a whole, the language is improving, and moving, and thats a positive thing in my mind. If it has to depreciate features to do it, thats *extremely* common in programming languages and computer apps in general. Its par for the course. Its the cost of getting improvements, and in the case of PHP, its a very well balanced trade generally.Gambler wrote:Because I was speaking about motion of the language as a whole. And my point is that the total subset of features that are... Well, I hope you get the meaning.For what reason?Whether it is possible to fix them is not important.
I agree with that. There is definitely pain for both sides at each step. Personally, I think the balance they've struck is near ideal.Gambler wrote:I'm not suggesting to maintain 100% compatibility at all costs. I'm saying that current "incremental upgrade" tactics is a half-way solution. It not perfect for the people who want incompatible new features, and neither it it the best for people who want compatibility without headaches.
Thats actually an implementation detail. You can do that today! By keeping the branches seperate, the PHP group gives the best of multiple worlds - you can implement things that way, or another way.Gambler wrote:There are other solutions, which would be more desirable for both parties. One of them is to isolate different versions. For example, .php files would be executed by PHP 4, while .php5 files would be used by PHP 5.
There is no perfect solution. The difference is that in watching how they've handled things since php3, I think they have the balance right this time, and you don't.Gambler wrote:Plus, I did not expect PHP 6 to be released so soon, and I hoped that developers would somehow solve compatibility problem in sixth version.
I disagree. Definitions do change the situation quite a bit. All your argument is trying to claim is that "Everyone usually uses the term the way I am defining it", without context. As I said, scripts that are maintained generally can drop in php5 as a replacement for php4. By way of example, phpbb's current version runs fine without modification on php4 or php5. Of course, a version of phpbb from a year ago will not. Thats the difference in definition being very important, and I'm sorry, in my opinion, most people do not use the term "Drop-in" to require permanent, 100% compatibility with every script ever written for any version of a language.Gambler wrote:If scripts have to be somehow changed to be up-to-date, than it is not a drop-in replacement. This has nothing to do with my definitions, as long as you use the term "drop-in replacement" the way people usually use it.
Magic_quotes is a great one. In php4, you have to check if magic_quotes is enabled. If it is, there are several different variants of magic_quotes that could be enabled, each of which having a different effect on the input. You then have to selectively *undo* that effect, and then apply your own transformation to be consistent.Gambler wrote:Examples?Actually, its becoming more consistent
Thats not true at all. Register_globals seriously breaks BC, and it had to be killed to do the right thing. Same for magic_quotes. Same for several others.Gambler wrote:True. That's because they usually do not consider features that would seriously break BC in the first place.They are rarely rejecting features on that ground.
Its neither abused, nor invalid, and while it is not exclusive to opensource, it is more relevant for opensource.Gambler wrote:This is one of the 10 most abused "arguments" on the web. It simply questions the right of a person to say certain things, rather than showing that person is erroneous in his conclusions. It is neither valid, nor exclusive for open source, and can be used to defend pretty much anything without providing any reasoning.As with so many opensource projects, if you think you can do better, step up. Otherwise, give some appreciation to the people working hard to make a fairly solid product - at least solid enough that you use it on a regular basis. You are always welcome to use something else.
Its not a meta-argument at all. Its a completely on-topic suggestion to help you understand why your arguments are flawed. They've already DONE the things you are suggesting (php3/php4/php5 as extension), and they've seen the impact, and they've chosen not to do it again for a reason. You've already shown that your difference in experience makes your arguments less valid than theirs based on experience, I just pointed it out in a clear fashion.Gambler wrote:See? Anything. Of course, I did not mean that, but I suggest you to refrain from such meta-arguments in the future, and deal with the topics at hand.