But in reality they only a minority of hosts offer that, because not enough developers ask for it. Backwards compatability fears might just be one of the reasons. If the clients don't ask for it, why should hosting companies upgrade.d11wtq wrote:I don't get it. Hosts can run both versions... I do on my VDS.
When you sign up for hosting they can just ask if you want PHP4 or PHP5. You could even have the option to switch via a control panel.
PHP6 - A look ahead
Moderator: General Moderators
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
True... but it's such a trivial thing. You can run one as a module and one as CGI, or better for shared hosts, just run both with CGI. Any directories can be pre-configured to use either one or the other... I'm surprised they've not had enough demand to do it. Maybe I've got a flase perception that more people use 5 than what they do. I've been using it for ages.... and I'll probably run PHP6 alongside when that's released too.
Hmm... maybe I should go into webhosting
Hmm... maybe I should go into webhosting
-
fastfingertips
- Forum Contributor
- Posts: 242
- Joined: Sun Dec 28, 2003 1:40 am
- Contact:
In my opinion web host providers and large companies are waiting to see not only where PHP is going to but also they are waiting for a stable point. We stayed a long period on a PHP4 and now everything is moving to much faster, php 5 is not even complete and we are already talking about PHP6.
So it's obvious why not many people are willing to develop using a PHP 5 platform when soon we will have PHP6, expecially if we are talking about large applications.
So it's obvious why not many people are willing to develop using a PHP 5 platform when soon we will have PHP6, expecially if we are talking about large applications.
PHP becomes increasingly unstable in terms of compatibility. If they release php 6 any time soon, writing scripts that are even remotely portable will become impossible. But that is merely an effect of the greater problem - short-sighted design decisions that try to please everyone instead of trying to achieve something objectively good. Personally, I would prefer to have one major breakup point, rather than many incremental changes, which only go half-way in fixing problems.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Technically its quite easy to write a large scale application for PHP4 that will work with PHP5 and PHP6 (assuming a bit here in terms of BC for PHP6 functions). The problem is you have to sacrifice the PHP5 OOM improvements, etc to do it. I'm not saying coding for PHP5 is bad (its the opposite) just than many OS projects feel confined to PHP4 until hosts upgrade above I think 5-7%? PHP5 penetration thus far.
Maybe its just me coding within PHP4 specifically but I honestly think most of the so called backwards compatibility problems legacy apps have is mostly bad design rather than PHP's fault. I've seen apps written originally for PHP3 run like clockwork under PHP5 with minimal changes.
It's a vicious circle. The hosts won't upgrade to support some PHP4 applications, the app developers won't migrate fully to PHP5 because 95% of hosts run PHP4 by default, and you come full circle. It's just one motivation - probably getting a bit old at this stage too
. Still a few hosts on PHP 4.3.x so I think a lot is just laziness and a touch of complacency.
Maybe its just me coding within PHP4 specifically but I honestly think most of the so called backwards compatibility problems legacy apps have is mostly bad design rather than PHP's fault. I've seen apps written originally for PHP3 run like clockwork under PHP5 with minimal changes.
It's stupidly easy I agree - I do it on my PC for development using a few small httpd.conf edits. Hosts just don't feel the motivation to do so on a large scale. And for a lot of non-developers requiring PHP5 has a frightening effect on available hosting options.I don't get it. Hosts can run both versions... I do on my VDS.
When you sign up for hosting they can just ask if you want PHP4 or PHP5. You could even have the option to switch via a control panel.
It's a vicious circle. The hosts won't upgrade to support some PHP4 applications, the app developers won't migrate fully to PHP5 because 95% of hosts run PHP4 by default, and you come full circle. It's just one motivation - probably getting a bit old at this stage too
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
I agree... Many of these host will simply have done a clean CPanel installation and everything they do in terms of maintenance will be provided by CPanel. I wonder how many providers would cope without things like this? I know when I was with my last shared host the "Technical Support" always used to responds with things like "Well it's just what ever came with CPanel.."Maugrim_The_Reaper wrote:Still a few hosts on PHP 4.3.x so I think a lot is just laziness and a touch of complacency.
Actually, if you code well, and don't use any deprecated functions, code written for php4 will work perfectly in php6. There are (I may get the exact number wrong) roughly half-a-dozen commands or structures from php4 that don't work in php6. Its *that* small.Gambler wrote:PHP becomes increasingly unstable in terms of compatibility. If they release php 6 any time soon, writing scripts that are even remotely portable will become impossible. But that is merely an effect of the greater problem - short-sighted design decisions that try to please everyone instead of trying to achieve something objectively good. Personally, I would prefer to have one major breakup point, rather than many incremental changes, which only go half-way in fixing problems.
PHP5 didn't even break things that much, with the notable exception of Public/Private, but if you had E_STRICT off, even that was perfectly workable (PHP6 doesn't object to that issue).
PHP6 is just the opposite of short-sited design decisions. Its a major restructure that removes a huge number of legacy cruft to make a better design overall. It removes over half of the deprecated items in php.ini, and adds unicode throughout. Thats a heck of a great redesign, considering that most PHP4 apps can work with minor changes on PHP6.
In my current situation i'm not in the situation to choose hosting for companies.. They come with their code and php environment.. And i have to write code for that situation... Like it or not. (I must admit that i'm fed up with that and have more or less stopped writing php code for money anyway..)
I have never experienced any serious problems when i migrated from php4 to php5 so i can only confirm that it's more or less a painful transition if the code is well written..
Earlier this day Rasmus posted a couple of benchmarks on the php.internals ML showing that php4.4 was faster than php5.1..
I have never experienced any serious problems when i migrated from php4 to php5 so i can only confirm that it's more or less a painful transition if the code is well written..
Earlier this day Rasmus posted a couple of benchmarks on the php.internals ML showing that php4.4 was faster than php5.1..
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
PHP 5 changed enough things to break some scripts. Whether it is possible to fix them is not important. The point is that total subset of version-portable and good-practice features decreases with each new release. As an additional bonus, syntax of each new language version becomes more and more incosistent. (Good example is define() and const.)
Another aspect of the same thing. PHP 5 is not a drop-in replacement for PHP 4. That is why hosting companies are so unwilling to upgrade.
PHP engine developers, however, think about PHP 5 as drop-in replacement for PHP 4. 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.
Another aspect of the same thing. PHP 5 is not a drop-in replacement for PHP 4. That is why hosting companies are so unwilling to upgrade.
PHP engine developers, however, think about PHP 5 as drop-in replacement for PHP 4. 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.
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
Is this the post your referring to?timvw wrote:Earlier this day Rasmus posted a couple of benchmarks on the php.internals ML showing that php4.4 was faster than php5.1..
http://news.php.net/php.internals/22357
Graph of benchmark from above post:
http://lerdorf.com/php/bm.html
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Here here.... not sure what you're getting at there Gambler.feyd wrote:define() and const are for different things.
I know some things have changed, but most of them are additions as opposed to actual changes. Constructors, new keywords, accessors and overloaded methods.
I've only ever had *one* PHP4 --> PHP5 issue. That was vBulletin. One of the array function specs has been changed (cant remember which) so that needle and haystack are the correct way around.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
You know, you can try out PHP6 if you really wanted to. To Windows users like me, http://snaps.php.net/ is tremendous. I actually have an old snapshot of php6 installed on my system. The interesting thing is the changelog, for what has actually changed (as opposed to what they want to change):
Code: Select all
PHP NEWS
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
?? ??? ????, PHP 6.0
- Unicode support. (Andrei, Dmitry, et al)
- Cleaned CGI code. Now FastCGI can not be disabled. See sapi/cgi/CHANGES
for more details. (Dmitry)
- Removed support for "continue" and "break" operators with non-constant
operands. (Dmitry)
- Changed __toString() behavior to call it in all necessary places
(Marcus, Dmitry)
- Changed "instanceof" and "catch" operators, is_a() and is_subclass_of()
functions to not call __autoload(). (Dmitry)
- Removed global reflection constants. (Johannes)
- Added "allow_url_include" ini directive to be able to turn off remote url
code execution separately from the "allow_url_fopen" setting. (Rasmus)
- Added to cURL extension: (Ilia)
. curl_setopt_array() which allows setting of multiple cURL options.
. CURLINFO_HEADER_OUT constant to facilitate request retrieval.
- Added --rclass and --rextension CLI parameters to reflect internal classes
and loaded extensions. (Johannes)
- Added optional parameter to http_build_query() to allow specification of
string separator. (Ilia)
- Added an optional parameter to parse_url() to allow retrieval of distinct URL
components. (Ilia)
- Added an optional parameter to strstr() and stristr() for retrieval of either
the part of haystack before or after first occurence of needle. (Johannes)
- Added possibility to check in which extension an internal function was
defined using reflection API. (Johannes)
- Fixed bug #34286 (__toString() behavior is inconsistent). (Marcus)