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.
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:Whether it is possible to fix them is not important.
For what reason?
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.
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: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.
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: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.
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.
As a side note, there is a *very* good reason why PHP doesn't do that by default. They did so in php3 and php4, and doing so resulted in *thousands* of apps having to be recoded to include/require/etc files with .php3 to .php4. It still causes a break, is the point, and by making that the default behavior, it breaks all scripts with the "wrong" extension by default. When in fact, the vast majority of php4 apps can, and do, run fine on php5 with little or no change.
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.
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: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.
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:Actually, its becoming more consistent
Examples?
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.
Compare with php6, which eliminates that setting, allowing you to know that the environment on *every* host is consistent. There is no transformation applied to your input. There is no variation on how that transformation is applied. There is no variation on which transformation is applied, and so forth.
Thats *much* more consistent, and it deeply simplifies the work you have to do in a script. Thats a great thing.
Gambler wrote:They are rarely rejecting features on that ground.
True. That's because they usually do not consider features that would seriously break BC in the first place.
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: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.
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.
Its neither abused, nor invalid, and while it is not exclusive to opensource, it is more relevant for opensource.
If you complained about Microsoft products, no one could reasonably say "Then help them fix the bugs", because its a closed-development process.
In opensource, *actually helping* is a real option. That you choose not to do so *is* a valid point to bring up. The PHP group has been hard at work on PHP for over 5 years, balancing between compatibility and impact the entire time, across 5 major branches (PHP/FI, PHP3, PHP4, PHP5, PHP6). They have seen thousands of companies and individuals impacted, and there are reasons behind their decisions drawn from those experiences.
To armchair quarterback, and claim they aren't doing it right, isn't constructive or helpful. Its sniping and complaining. If it were Microsoft, you could reasonably respond that you don't have the option to help, so you are limited to providing feedback, and that would be a legitimate statement.
Its entirely valid to suggest to someone complaining about a situation to try to improve it. Its an extremely old concept - walk a mile in a mans shoes? The point is that you do not understand the reasoning behind their decisions, and (almost definitely) cannot until you go through the same experiences they have. So until and unless you are willing to do so, your arguments have infinitely less value. They've felt the pain (including financially!) of their decisions. You sit on the sidelines and comment. Which is more informed, reasonable, and pain-driven?
Thats why the argument is entirely valid.
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.
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.
I suggest, as I have numerous times, that you focus on being constructively helpful instead of sniping. Granted,
that is a meta-discussion, but it bears repeating.