Comments on: PHP 6.0 Ingredients http://www.sitepoint.com/blogs/2005/08/15/php-60-ingredients/ News, opinion, and fresh thinking for web developers and designers. The official podcast of sitepoint.com. Tue, 02 Dec 2008 07:08:01 +0000 http://wordpress.org/?v=2.5 By: Alexander http://www.sitepoint.com/blogs/2005/08/15/php-60-ingredients/#comment-28104 Alexander Wed, 31 May 2006 19:53:08 +0000 488362191#comment-28104 What is the most important information I should know about Cymbalta? What is the most important information I should know about Cymbalta?

]]> By: Tomas Matousek http://www.sitepoint.com/blogs/2005/08/15/php-60-ingredients/#comment-10642 Tomas Matousek Wed, 09 Nov 2005 13:51:04 +0000 488362191#comment-10642 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 ... 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 …

]]> By: Rokas http://www.sitepoint.com/blogs/2005/08/15/php-60-ingredients/#comment-8144 Rokas Fri, 19 Aug 2005 12:50:47 +0000 488362191#comment-8144 <blockquote></blockquote><blockquote>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!</blockquote> 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).

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!

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).

]]> By: rchurch http://www.sitepoint.com/blogs/2005/08/15/php-60-ingredients/#comment-8141 rchurch Fri, 19 Aug 2005 10:16:59 +0000 488362191#comment-8141 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 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

]]> By: Paulg http://www.sitepoint.com/blogs/2005/08/15/php-60-ingredients/#comment-8140 Paulg Fri, 19 Aug 2005 09:16:12 +0000 488362191#comment-8140 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 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

]]> By: Pie http://www.sitepoint.com/blogs/2005/08/15/php-60-ingredients/#comment-2395 Pie Wed, 31 Dec 1969 19:00:00 +0000 488362191#comment-2395 <p>PHP 6 already? I think they should focus on improving 5.0.. backwards compatibility etc.</p> <p>The people who are on PHP5... will have both 4-5 and 5-6 backwards compatibility to deal with</p> 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

]]> By: Etnu http://www.sitepoint.com/blogs/2005/08/15/php-60-ingredients/#comment-2396 Etnu Wed, 31 Dec 1969 19:00:00 +0000 488362191#comment-2396 <p>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".</p> <p>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.</p> 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.

]]> By: scoates http://www.sitepoint.com/blogs/2005/08/15/php-60-ingredients/#comment-2397 scoates Wed, 31 Dec 1969 19:00:00 +0000 488362191#comment-2397 <p>Sorry to be plugging myself, but I discuss the input filter thing a little more deeply in <a href="http://blog.phpdoc.info/archives/21-Suddenly-5.1-Isnt-So-Exciting.html#extended">a post on my blog</a>.</p> <p>S</p> Sorry to be plugging myself, but I discuss the input filter thing a little more deeply in a post on my blog.

S

]]> By: shiflett http://www.sitepoint.com/blogs/2005/08/15/php-60-ingredients/#comment-2398 shiflett Wed, 31 Dec 1969 19:00:00 +0000 488362191#comment-2398 <p>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.</p> <p>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).</p> <p>Here's more information:</p> <p>http://files.derickrethans.nl/filter_extension.html</p> 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

]]> By: johno http://www.sitepoint.com/blogs/2005/08/15/php-60-ingredients/#comment-2399 johno Wed, 31 Dec 1969 19:00:00 +0000 488362191#comment-2399 <p>With packages and "finally" for exceptions please!</p> With packages and “finally” for exceptions please!

]]>