PHP6 - A look ahead

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

We're just installing a CVS version now.

Not sure where the docs are though (if there even are any yet).

Will possibly post later with any interesting, early findings :)
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

Gambler wrote:PHP 5 changed enough things to break some scripts.
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:Whether it is possible to fix them is not important.
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:The point is that total subset of version-portable and good-practice features decreases with each new release.
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.

Choosing to *never* eliminate legacy would result in Perl. (Just kidding). It would result in a never changing language that has a consistently declining value in the realworld. Just like applications that haven't been updated in years.
Gambler wrote:As an additional bonus, syntax of each new language version becomes more and more incosistent. (Good example is define() and const.)
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: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.
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.
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!

They are trying to strike a balance between removing kruft and legacy mess, improving best practice, and stability, while adding new functionality.

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's always Perl. :)
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

Roja wrote:You are always welcome to use something else. There's always Perl. :)
I was going to post that but I decided not to :P :lol: Actually, i quite like Perl... but mostly for it's cool regex magic 8)
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

Well I can get it running but only as a module. Since I have five IP's can anyone tell me how to run multiple instances of apache?

I'll run it on a spare IP and keep fetching CVS snapshots every couple of days :)
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

If i'm not mistaken somewhere at the top of httpd.conf you can configure to which network interfaces (ip's) apache should try to bind... Default it binds to * (all).

If you're using the cgi versions you could simply setup a couple of different /cgi-bin directories (and associated php-cgi versions)
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

Maybe it's not useful to you d11wtq but maybe to some others reading this thread: I just installed a couple of apache servers on USB sticks (http://www.chsoftware.net/en/). Installs in a few minutes and you can run and switch between php 4 and 5 in a second. Pretty cool to be able to run websites from a tiny usb. Also good when presenting websites/app to a client and the local internet connection is broken (should have known about this earlier ... ugh :? )
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

Thanks for the input but you've both got me wrong :P

I don't want the same apache instance running because I'm trying to run two SAPI modules for different versions of PHP. I need *two separate* instance running on two different IP's (same machine).

I already have two installations with the config files set to bind to different IP's but I just get an error that the PID file aready exists when I try to start the second one :(
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

Hmm... I think my problem is that I tried to take a cheeky shortcut and just copy the binary files to another dir for apache.

I'll try a fresh compile from source with another --prefix and see if that works better :) I don;t see why you can't run two instances if they're not binding to the same IP :)
Gambler
Forum Contributor
Posts: 246
Joined: Thu Dec 08, 2005 7:10 pm

Post by Gambler »

The first part is correct, the second part is not.
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.
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.
Choosing to *never* eliminate legacy would result in Perl.
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.
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.
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.
Actually, its becoming more consistent
Examples?
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.
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. In fact, I can use the same pattern to defend my posts. Here it goes.

Instead of criticizing my posts and arguing with me, you can alway posts you own opinion on the matter independently. You are free to ignore my posts, if you don't like them.

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.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

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.
There is no arbitrary rule for what is important or not, so saying such a rule is misguidance.

I'm currently supporting a system, on which one application has not been changed, nor updated for 16 years. It contains all of the companies financial records, and is also used to track changes to other systems. It has been given the status of 'level 1' - i.e. it dies, the company dies.


Just highlighting a point incase someone now starts panicing because they haven't made an update for a 367day old app..
User avatar
AKA Panama Jack
Forum Regular
Posts: 878
Joined: Mon Nov 14, 2005 4:21 pm

Post by AKA Panama Jack »

Jcart wrote:
Earlier this day Rasmus posted a couple of benchmarks on the php.internals ML showing that php4.4 was faster than php5.1..
wow. 8O
I thought everyone knew that?

I posted about that in my blog around a year ago. :) PHP 5 has much larger overhead than PHP 4 in all areas which contributes to it being slower. That's probably one of the many reasons many sites are sticking with PHP 4. It puts far less strain on a server.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

Jenk wrote:
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.
There is no arbitrary rule for what is important or not, so saying such a rule is misguidance.
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.

Similarly, my comment around an application not being updated being unimportant.

There are definitely exceptions to both, and reasons why both wouldn't be true. Thats the problem with arguing absolutes - its trivial to find counter-examples.

So yes, I agree - there are exceptions to that statement. In general, I think most php apps need to be updated regularly to be useful and worthwhile, but I have found exceptions to that statement.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I'd say I generally agree with Roja on this subject. But an interesting point has been made about PHP. Several people noted that if you don't keep a PHP app up-to-date -- and the version of PHP keeps increasing (which is normal with web hosts) -- then the app will eventually break in little ways. I have and do program in a number of languages, and there is certainly some of this problem in every language. As has been noted, some languages like Perl (and in my experience Java as well) have very few problems like this. How unique do people think this problem is to PHP?

PS - Somewhere there was mention to "best practices" in various versions of PHP. I found this curious because it has always seemed to me that PHP has been generally missing in "best practices." There have usually been common practices, but more often than not those have been bad practices.
(#10850)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

I just think its interesting to look at both of aborint's paragraphs - how many times are both of these interelated? At this point avoiding backwards compatibility is not possible if the PHP devs wish to promote and enforce best practice. I wonder how many will complain about the past changes to the header() function to prevent splitting (pretty recent really).

Seems like a lot of these BC's are in many ways a requirement that if avoided would be simply perpetuate the problems experienced developers are aware of in security terms. I'm sure we could all bash PHP for failing to see these issues from the start, but that seems pretty pointless in hindsight.

BC is usually (not always, but in general for PHP) down to how you use PHP. As Roja would note, using the lowest common denominator set of features in PHP4 generally resulted in PHP5 migration being incredibly simple. If its horrendously difficult then someone (not PHP) went wrong somewhere along the line. Maybe my experiences have been unusual or I've been plain lucky...;)

At the end of the day we have to recognise that regardless of individual positions there are no winning tactics to improving PHP. It's a pointless thing to argue over - either its done, or we spend the next decade adjusting for those bad practices, and watching new developer after developer continue using the same old insecure badly implemented code so evident in PHP today.
Post Reply