In other news over the weekend, Rasmus posted his personal wish list of features for PHP 6.0. Comments in the SitePoint Forums about the proposals have largely been positive, with some caveats. Web hosts are concerned about backward-compatibility problems, mentioning that the break in compatibility between version 4.x and 5.0 is already proving a great problem, whereas the backward compatibility break between 5.x and 6.0 is set to be even greater.
Something that I have been very keen to see in PHP for a long time is proper support for character encodings including UTF-8. Currently, PHP has no internal Unicode support, though conversions can be done with the mbstring extension (sadly not enabled by default) or external tools like iconv. Writing a Web application that uses UTF-8 for its content can be difficult due to PHP’s assumption that all characters are one byte.
The php.general post itself contains the wish list, and its replies contain even more information and suggestions. Among the suggestions are a complete removal of register_globals and magic quotes – which, as you can probably guess, I think is a terrific idea. I am not as sure about his third suggestion, which involves some sort of input filter for get, post and cookie variables, as it reminds me a little of magic_quotes_gpc. However, the suggestions are very much hypothetical at this very early stage and shouldn’t be seen as an official indication of what PHP is working towards.
Head over to our forums to see further discussion about the wish list.
Related posts:
- How to Install PHP 5.3 on Windows PHP 5.3 is the most significant update since version 5.0....
- Are PHP Namespaces Really So Bad? Namespaces have caused a divide amongst developers who either love...
- PHP Support in NetBeans 6.5 Long dismissed as a "toy Java IDE", NetBeans - Sun's...
- Ready for PHP & MySQL Week at SitePoint? To celebrate the release of the new edition of well-loved...
- flippa.com: It’s Alive! Whip out your diaries, grab your pen, and let it...
PHP 6 already? I think they should focus on improving 5.0.. backwards compatibility etc.
The people who are on PHP5… will have both 4-5 and 5-6 backwards compatibility to deal with
August 15th, 2005 at 10:47 pm
Once again, I can’t believe people keep talking about “BC breakage” between 4.x and 5.0. I can say with about 99.9% certainty that nothing on your site will break, unless you consider generating a few extra notices / warnings “breaking”.
Everyone I know who thinks there’s a bc problem with 5.x has never even tried running a server with it. Try it. You can even run them simultaneously — it’s not that difficult.
August 15th, 2005 at 10:52 pm
Sorry to be plugging myself, but I discuss the input filter thing a little more deeply in a post on my blog.
S
August 16th, 2005 at 12:07 am
One huge difference between the input filter extension (as proposed – it’s still in the design stage) and something like magic_quotes_gpc is that the developer has control. Developers can still access raw data.
Another difference is that the purpose of the input filter extension is primarily filtering. There will likely be some escaping options (one specifically to mimic magic_quotes_gpc to help with BC), but the focus is on filtering. The input stage is where filtering should happen, and the primary source of input is the user, so this is where an extension can help the most (other sources of input might be unique to your application and not easily identified by a mechanism like this).
Here’s more information:
http://files.derickrethans.nl/filter_extension.html
August 16th, 2005 at 12:11 am
With packages and “finally” for exceptions please!
August 16th, 2005 at 4:45 am
The discussion about PHP 6.0 is at an very early stage and nothing is written in stone.
If someone is afraid of a BC break, he is doing something wrong. Removing register_globals shouldn’t matter at it should be off anyway. Removing magic_quotes shouldn’t matter either as the developer should escape himself instead of trusting an escaping, that doesn’t even work with all databases.
Namespaces could finally become part of PHP, maybe named paramters. This is stuff like the PHP5 additions – if you use it it could make your life easier – if you don’t your code keeps working.
The only thing that is really new and could affect existing code is the unicode support. That’s why it’s called PHP 6. I guess this time the dev team will make it easier to user PHP5 and PHP6 at the same time – like with 3 and 4. Thus this won’t be a problem either.
So know one should need to cry “oh my god” and even if, it’s to early yet – everything, except unicode, can change – that’s why it’s called whishlist.
b4n
August 16th, 2005 at 5:38 am
It’s nice to hear that there’s no “BC breakage” with PHP 5, now then we can start selling our products saying that they’re working with PHP 5 even if half of the external library we use says they’re not actually working with PHP 5 :)
Jokes apart, this feature list for PHP 6 is quite interesting. As a coder I really appreciate the efforts that are being made to improve PHP. As a sales person I’ll move to hire Java coders since with a BC Break at each major release it’s impossible for us to sell PHP applications to big enterprises like banks, they simply don’t trust it and are deeply convinced that within some years the applications they’ve spent big $$ for will require more money to be fixed. This can be true or not but it’s really what big company thinks.
August 16th, 2005 at 7:32 am
“As a sales person I’ll move to hire Java coders since with a BC Break at each major release it’s impossible for us to sell PHP applications to big enterprises like banks, they simply don’t trust it”
And their ASP investments are REALLY payng off, right? Isn’t ASP.NET completely non-BC?
- Davey
August 16th, 2005 at 7:41 am
The Unicode support will be, in my opinion, the number one reason why people upgrade to 6. Really, why not build it into 5? It is *so* overdue, I can’t believe it.
August 16th, 2005 at 8:17 am
I think it is w-a-a-a-y too soon to talk about PHP 6 until PHP 5 has gained more acceptance.
I agree with points 1, 2, 4 and 5.
Point 3 might be useful, but I don’t see any major benefits over my own filtering system.
With point 6 I would only remove stuff from versions that are no longer used. Nobody (with any sense, that is) uses PHP 3 any more, so that can safely go. All the while there are tons of developers using PHP 4 then the deprecated items should be left in to enable a smooth transition.
With item 8 I would rather see more function aliases instead of less. I would not remove any as they may break existing code, and not breaking BC is MUCH more important than theoretical language purity. Besides which different programmers will have a totally different view on what is pure and what isn’t. I would add MORE aliases to counter those arguments of inconsistent function names. For example, all string manipulation functions should begin with “str_”.
As for item 7 (more case-sensitivity) I think this is total CRAP. Having case-sensitive names causes more problems than it solves, so leave it out. I have worked for 30 years with operating systems and programming languages which were totally insensitive to case, and I hate it when all of a sudden it becomes important. Whether something is written in uppercase or lowercase should be irrelevant. Case does not change the meaning of a word in any spoken or written language, so there is no justification for doing so in a programming language.
August 16th, 2005 at 9:26 am
With AJAX I found unicode support becomes more important. After much research, I found these 2 PHP functions: utf8_encode(),utf8_decode() in the XML extension. Still, they only translate from/to ISO-8859-1.
August 16th, 2005 at 10:04 am
Davey, infact I talked about Java :) In my mind ASP just mean Application service provider :)
August 16th, 2005 at 10:34 am
I too would think that the best deal would be to get PHP5 out first and leave it to settle for a while before moving forwards.
Unicode should have been a part of PHP5 to begin with anyways, more importantly than namespaces for example?
Namespaces or the lack of, as developers we can relatively easily work around that, not so with character encoding, and the troubles that entails :(
As for PHP6, -BEEP- it, we need to get developers starting to develop for PHP5, never mind anything else. That should be the priority, now that PHP5 is here.
Also, for a lot of developers, myself included, BC is not an issue, and to those that it is an issue, it’s an issue due to fear of the unknown.
Fear of moving forwards… What is the -BEEP- point of having PHP5 is people are not prepared to develop for it, from a clean slate huh?
There is just nothing in it really. Can I calm down now??
August 16th, 2005 at 11:26 am
I believe the reason behind giving the name 6.0 is that Unicode support is really going to change a lot of the internal structure of the language. The issue of BC is larely over exaggerated. Perhaps if you’re converting an early PHP4 app that uses register_globals to PHP5, you’ll need to spend some time actually making changes, but that’s not an artifact of PHP5, it’s an artifact of register_globals. I’m not so sure that the problem is with developers not moving to PHP5, personally I prefer it, because it makes my life easier, but I have a hard time trying to convince the boss to let me install PHP5 (even though it’s been stable for a solid year now). One could debate for hours on the points of why PHP5 pickup has been so lackluster, and I’m sure many here have already been involved in said debate, but I imagine over time use of PHP5 will gradually increase, and PHP6 (although it’s still conceptual) can be something to help that.
August 16th, 2005 at 12:02 pm
>PHP 6 already? I think they should focus on improving 5.0
Maybe… but what is wrong with brainstorming?
>Everyone I know who thinks there’s a bc problem with 5.x has never even tried running a server with it.
I agree to some extent with this… IMHO, I must admit that from what I have seen, a lot of people (ISP/Hosts included) do not understand how to install/configure a production PHP server. Let alone a version 4/5 side-by-side, which is pretty trivial these days, but some people make it seem hard. I see no justification in that argument.
I like the input filter idea… I’d say if it is used, let it be used, but do not let the developer have a way out… If this is going to be an admin feature, let it be used in that way and that way only.
>it’s impossible for us to sell PHP applications to big enterprises like banks
That is because you are selling applications without support. Support would be in the form of a PHP installation/configuration for that app… does the app work? is it secure? if so, then why upgrade PHP4-5… if you are upgrading php4-5 to solve a problem, maybe the app wasn’t all that great in the first place?
Anyway, just some minor observations…
August 16th, 2005 at 3:26 pm
I must have missed something with the comments about it being easy to run 4/5 side by side. From my observations and trials, you can only have ONE installation as an Apache module, the other has to be as a cgi due to the internal mime types that the module uses. There are ways of running two modules side by side, but you either have to use a convoluted proxy solution, or change the source code and recompile to alter the mime type, or run one as a cgi. Either way you cant easily switch your code between interperaters easily without either including a shell interpreter line at the start of your index scripts and renaming the file extensions.
It would be nice for those of us in the hosting business if we could finally run them both on the same web server with minimal impact on the rest of the system. Anyone tried to run a php4 script as a module, then call a php5 script as a cgi from the php4 script? Its one sure fire way to bring your server down to a screaming halt.
Wonder what ever happened to the original discussions about php6 potentially running on the Parrot engine? Glad to see that a built in opcode cache is finally being considered as well.
August 16th, 2005 at 7:40 pm
I’m astonished to hear some of the comments listed. Firstly let me distinctly state, PHP5 is not completely backwards compatible (BC) and as mentioned BC, is largely over exaggerated. My first concern is the stability of PHP5. The mention of namespaces when the conceptual idea came about was nice to have, however now I could care less. There are far too many disagreements with its implementation, and if need be mimic this in PHP, you only a need a little intuition to figure out how.
Has anyone actually read through the ICU documents? (It gave me a headache) However, even with the implementation of ICU, I would still state that it would be quite cumbersome without an enormous amount of work to implement seamlessly and even then peoples approaches would be questionable.
“As a sales person I’ll move to hire Java coders since with a BC Break at each major release it’s impossible for us to sell PHP applications to big enterprises like banks, they simply don’t trust it”
My interpretation of your understanding would be for you to re-evaluate. I remember having this rather immature comparison, when I was starting out. Whilst PHP wouldn’t be the language of choice, it doesn’t match up with banking infrastructure; have a look at SWIFT (http://www.swift.com). Can you imagine, selling 20 million pounds worth of banking software in PHP? Also at last mention I was told banks wouldn’t touch .NET. There are plenty of reasons why banking software is not in PHP, and I am pretty sure they have nothing to do with support.
There are plenty of functions and classes available in PHP as is, and having aliases are counter intuitive and adds extra learning curves in my opinion. The dominant function name for each should be elected, and the documentation’s presentation should distinguish these as recommended.
“I have a hard time trying to convince the boss to let me install PHP5 (even though it’s been stable for a solid year now).”
It doesn’t matter how long a language has been out, you’ll find people ignorant of change or willing to learn.
Quoting the DR…
“PHP is already Enterprise Ready, more so with PHP5 which offers the developer more control. If someone determines that PHP is not yet, already enterprise ready, then they’re either ignorant or speaking horse manure (putting it politely, that is)”
Well, I’ll disagree (I’m ignorant), some recent enterprise projects I am currently working on…
How many products integrate PHP with Crystal Reports? (We cannot rely on COM).
BusinessObjects InfoView – JSP & ASP.NET versions…
Microsoft SharePoint Portal Server 2003
Blackberry
One of the fundamental problems I find is that there is a lack of projects / examples of working with integrating current enterprise software. The question is why?
August 16th, 2005 at 9:13 pm
>From my observations and trials, you can only have ONE installation as an Apache module, the other has to be as a cgi
Yes, actually, I neglected to mention that. I realized quite long ago that it is better to run PHP as a CGI. I have not yet found a case where the module was better. I have read more cases on the net about the module being faster and more stable, but from my experience, it is not.
I have tested this many times. I haven’t do any tests against PHP5, but I can’t imagine (just a guess) that PHP5 does anything different that would change this.
With that said… even if there is some gain from using the module which I am unaware of, unless it is something spectacular, I see no reason to choose the module, which is less flexible from an installation and configuration standpoint, over the CGI.
Again, I do apologize for leaving that tidbit out of the original post… I’ve just been doing it for so long that I took it for granted.
If anyone has anything to add, I’d love to hear it. I haven’t checked into this in a while, so I’d like to hear if anything has changed.
August 17th, 2005 at 12:29 am
Thats BS about non-BC of php5. I have done a heavy script under php5 on my dev machine and when finished it and moved to server which actually had php4(latest version), the script didn’t work. But finding what breaks there would have costed too much invaluable time, so we just switched server to php5. Guess what happened. Nothing! Except that my new script actually worked. None of the old code broke!
August 17th, 2005 at 4:47 am
@Davey
well, in posting this comment, you simply demonstrate how mis-informed you are!! *rolleyes* PHP5 is the next version of PHP4 in the sense that they use the same engine & same file extension, while ASP & ASP.NET are two different things with 2 different engines & file extensions, so when you install .NET on an IIS server, it doesn’t do anything to your ASP applications but that’s not the case with PHP4 & PHP5. Besides, I know its possible to have both PHP4 & PHP5 installed & working on a server(by passing the path of the PHP5 installation at the top of every PHP5 script), but really, how common is that??
August 17th, 2005 at 4:57 am
Uhh… what are you talking about? They never claimed php4 had php5 support.. maybe you need to re-read your post.. Of course your php5 stuff wouldn’t work on your php4 server… that has nothing to do with BC…
August 17th, 2005 at 6:15 am
I imagine over time use of PHP5 will gradually increase, and PHP6 (although it’s still conceptual) can be something to help that.
————-
yes,I think so
August 18th, 2005 at 2:07 am
The one biggest thing I would love to see is consistency in the naming and operation of functions. All function should use the same naming convention and the same implementation.
August 18th, 2005 at 12:16 pm
In practice, if you have been keeping up with changes in 4.1-4.3 there are few BC issues that I found moving to php5.
What would I like to see in php6?
How about getting back to its roots? a lang to make the development and maintainance of websites easier.
-Make it easier to use Ajax/rpc
-As said, help us cleanse and shakedown incoming data natively without us all having to write and maintain “datascrubbers”
Build in Xforms
HTML tidy addition was a superb move in php5, building in webstandard compliance for everyone.
Cheers
August 19th, 2005 at 5:16 am
PHP5 take up is slow, because the developers of Web Hosting Panels like Plesk and Cpanel don’t want to do the work of getting PHP5 and PHP 4 to work side by side. It should be fairly trivial, if proper default are set.
Get the handlers to use .php5 for PHP5 scripts and .php for PHP4 scripts or the converse shouldn’t be that difficult as well as running scripts to do global search and replaces where preferable shouldn’t be that difficult
August 19th, 2005 at 6:16 am
Uhh… what are you talking about? They never claimed php4 had php5 support.. maybe you need to re-read your post.. Of course your php5 stuff wouldn’t work on your php4 server… that has nothing to do with BC…
I don’t think you understood my post. I meant that none of 100+ scripts written on php4 broke up on php5, only php5 made one script work, which didn’t work on php4. That tells something about BC…
And that clearly tells that php5 should be used, instead of php4.
Although I wouldn’t really recommend to do that yet, if you don’t find some scripts not working on php4, because php5 still had few updates and so there might still be quite some bugs not found(didn’t notice any yet though).
August 19th, 2005 at 8:50 am
Well, ASP.NET and PHP needn’t necessary mutually exclude one other. Our project, Phalanger (http://php-compiler.net), enables to combine them. Besides, it can compile both PHP4 and PHP5 code and enables working with Unicode transparently – without changes to the code unless you use functions that should give different results in Unicode context. For that reasons we added some functions like ord_unicode, chr_unicode, to_binary etc. Though we have currently version 1.0 RC2 we are capable of compiling large PHP applications (phpBB, ADODB, OpenPhpNuke, Phorum, Smarty, GTK, …). We would like to get some feedback from PHP developers whether we are doing things right, so if you don’t like to wait for PHP6 just try it …
November 9th, 2005 at 9:51 am
What is the most important information I should know about Cymbalta?
June 1st, 2006 at 5:53 am