An Early Look At What's Coming In PHP V6

IndioMan writes "In this article, learn about the new PHP V6 features in detail. Learn how it is easier to use, more secure, and more suitable for internationalization. New PHP V6 features include improved support for Unicode, clean-up of several functions, improved extensions, engine additions, changes to OO functions, and PHP additions." Update — May 7th at 16:47 GMT by SS: IBM seems to have removed the article linked in the summary. Here's a different yet related article about the future of PHP, but it's a year old.

Finally

[Anonymous Coward]

It's about time PHP has native support for unicode.

Time to pay the piper...

[Onyma]

I am definitely no PHP expert so perhaps I am wrong but it seems that much of what is being changed is backtracking due to bad language decisions from the beginning. Sadly I think PHP developers with legacy code are going to be paying the price for several versions to come.

Re:So...

[77Punker]

Gotta break some eggs to make an omelet.

Hopefully this will include cleaning up the argument lists of the string and array functions so that they hall take f($needle, $haystack) in a consistent order. Fixing the argument lists isn't in TFA, but it's a really obvious place to start.

At work, it may give me an excuse to rewrite a horrible old app that's been holding us back since the days of PHP4. I suspect I am not alone in wanting to see some old (buggy, slow, insecure, poorly designed) PHP apps get ruined so that they can be redeveloped now that PHP5 is actually a decent language.

Re:Time to pay the piper...

[Anonymous Coward]

You're not far off track. A lot of PHP's problems stems from the fact that the language itself was more or less kind of thrown together rather than planned out (from the early simple Personal Home Page scripting stuff to PHP3 that just kept extending things and adding more functionality bolted on). They only just began to start to stabalize some of that in PHP4 and really only started to fix a lot of issues in PHP5 and now PHP6. They are making good strides but there's a lot of work to do (and a lot of backwards compatible considerations, I'm sure).

The good news for PHP developers with legacy code is that they've had a long time to fix things. Stuff that is going away has been deprecated for many versions now so none of this should be a surprise. The people that will get hit are the site administrators using PHP based apps that haven't been updated in forever.

question:

[larry bagina]

are these ass clowns still planning on using \ for namespaces?

A likely story

[Anonymous Coward]

As far as I can tell, PHP 6 is probably a long way off. End of 2009 at the very earliest. Consider this: PHP 5.3 introduced RC1 in March with the idea of 1-2 week intervals, and, here in May, we're still not at RC2.

Given that PHP 6 was "rumored" to be out at least a year ago. I can't decide if the title "An Early Look" is meant to be ironic, or is just a sad indicator of progress.

Despite that, I would say that three things have recently happened demonstrating the improvement in quality of PHP:

1. End of Life of PHP 4
2. Many important improvments in PHP 5.3
3. Unicode in PHP 6

I would say that (1) and (2) easily are more important for the language than is (3). PHP 5.3's improvements should be a huge change: Namespaces (I know there's a huge amount of hate for this implementation: get over it. It's going to be very useful), Closures / Lambda Functions, and Late Static Bindings in particular make it hard to wait so long for PHP 5.3.

So, stop talking about PHP 6! Lets get PHP 5.3 out.

Limited cleanup

[Just Some Guy]

clean-up of several functions

Does that include safe_quote_string_this_time_i_really_freaking_mean_it, or do_foo(needle, haystack) and foo_do(haystack, needle)? At least it gets namespaces after all this time, even if they're almost deliberately ugly.

My items to be fixed

[Parker Lewis]

My items to fix: - Remove the "goto" statement that will be introduced in 5.3 (WHY JESUS, WHY??); - Stardandize function names (current samples: str_replace, html_ entity_ decode, htmlentities, htmlspecialchars_decode); - Improve array speed (for simple arrays, use internally one simple C array/list - current days, any array is a map); - Insert optional configurations by project (and not by host); - Remove function alias; - Provide optional typing for functions and parameters, but in a simple and consistent way (no strange notations); - Remove old extensions, like PDF paid extensions (and please, insert any open and official PDF extension); - As any language, provide a way of store compiled regex, avoiding compile them all the simple regex call for the same task; - Provide legacy support for PHP5 application as separated download (or at least allow PHP6 and 5 in the same host - we suffer a lot to find PHP5 Hosting in the earlier times, due the impossibility of run PHP4 and 5 at the same host).

Re:Limited cleanup

[LWATCDR]

All I want is for $foo[0] and $foo["0"] to not be the same reference.

One of these things is not like the OOthers

[Ukab the Great]

One of these things just doesn't belong

python:

myArray.append(myvalue)

ruby:

myArray.push(myvalue)

objective-c:

[myArray addObject: myvalue]

smalltalk:

myArray add: myvalue

PHP:

array_push($myarray, $myvalue)

Re:Finally

[ShawnCplus]

There is the PHP GTK project but I'm a PHP developer and even I'm wondering why you would choose PHP for developing a GUI desktop app.

Re:question:

[Anonymous Coward]

Can't break some eggs without raping an omelette.

Well wouldn't you know

[omuls are tasty]

In the finest tradition of PHP, they made Unicode behaviour dependent on a setting. Have these people learnt nothing from the past? magic_quotes anyone? Bleh. All languages have their warts, but the amount of bad design decisions in this one is just staggering.

Re:Namespaces

[edsousa]

Say that $Foo=3
It will print
Hello 3


Because the namespace begins with a backslash ('\foo\n') and when using it inside double quoted strings must be "\\foo\\n".

Re:So...

[Anonymous Coward]

Perhaps your customers freak when they read your spelling.

Re:Finally

[rho]

Ubiquity is a pretty compelling feature.

I mean, BeOS is pretty bitchin', but I'm not spending any of my time on developing applications for it.

Re:My items to be fixed

[Anonymous Coward]

1. Remove the "goto" statement that will be introduced in 5.3 (WHY JESUS, WHY??);

   -1 It's a useful language construct with less overhead than exceptions. I'm going to overuse and misuse it out of spite for all those Dijkstra parrots who mindlessly repeat the mantra :-o

2. Stardandize function names (current samples: str_replace, html_ entity_ decode, htmlentities, htmlspecialchars_decode);

   +1

3. Improve array speed (for simple arrays, use internally one simple C array/list - current days, any array is a map);

   -1 Write an extension for carrays.

4. Insert optional configurations by project (and not by host);

   -1 You can already do this via .htaccess sans security resourse limits which should be per host on shared hosting.

5. Remove function alias;

   -1 Some of this is already done via namespaces, the problem was extensions like ming that defined rather generic aliases in the global namespace.

6. Provide optional typing for functions and parameters, but in a simple and consistent way (no strange notations);

   -1 PHP already has type hints.

7. Remove old extensions, like PDF paid extensions (and please, insert any open and official PDF extension);

   +1 Work to split off all but required bundled extensions into pecl begun some time back.

8. As any language, provide a way of store compiled regex, avoiding compile them all the simple regex call for the same task;

   ? I think APC will cache the compiled regex from PCRE?

9. Provide legacy support for PHP5 application as separated download (or at least allow PHP6 and 5 in the same host - we suffer a lot to find PHP5 Hosting in the earlier times, due the impossibility of run PHP4 and 5 at the same host).

   ? You can already do this with cgi, fcgi and there's workarounds (ie: proxy) for mod_php.

Indeed it does not

[SmallFurryCreature]

Market share: PHP 50%, ASP 49%, rest perl.

When PHP and ASP don't totally dominate the job listings, please come back to me again. In the meantime I know which of the function calls pays for my food.

Oh and $array[] = $value;

Coding, you should learn it.

Re:My items to be fixed

[mgkimsal2]

# Insert optional configurations by project (and not by host);

-1 You can already do this via .htaccess sans security resourse limits which should be per host on shared hosting.

.htaccess only works under Apache, and then only in the context of a web request. If I'm working PHP shell scripts, .htaccess is useless to me.

Re:Hope it handles Search/Replace better

[Just Some Guy]

Loading 88MB file into memory is not going to work by default anyhow, unless you set the memory limit in PHP from the default you will get out of memory errors every time. I think even a find/replace in a Windows app like Notepad or Notepad++ will "work" but it will definitely be slow. When I used to search large logs I would use some sort of file splitter and search each file itself.

And here the rest of us are grepping and sedding multi-gigabyte files without thinking twice. Seriously, what's your idea of a large file?

Re:Well wouldn't you know

[VGPowerlord]

Stack Overflow has a question from last year titled Worst PHP practice found in your experience?. Earlier today, I submitted the answer whose summary is "The worst practice in PHP is having the language's behavior change based on a settings file."

Great minds think alike!

Re:A likely story

[amicusNYCL]

It's no defense, but the guy who started PHP, Rasmus Lerdorf, is apparently a Danish Greenlander, and the two guys who rebuilt the parser for PHP3 and on, and founded Zend, Andy Gutmans and Zeev Suraski, are both Israeli. As I said, it's no defense, but Americans didn't have anything to do with creating PHP.

Re:question:

[Anonymous Coward]

Worst design decision? Wow, that'd be quite a compliment for PHP -- as Dragonslicer notes, there's, for example, magic_quotes.

It's just a token, people, get over it. There was nowhere nearly as much brouhaha for Python's // operator (that looks like a C++ comment), or the ambiguity of the dot in Java, or VB's \ operator, or the fact that -- in Haskell starts a comment but --# is an operator, and the list goes on.

Re:Object Oriented support in PHP

[shutdown -p now]

PHP5 has a fairly proper inheritance and member visibility model and is truly reference based (i.e. $objX = $objY means, in PHP5, that they are reference to the same object instance... opposed to PHP4 where $objX = $objY made a FULL copy of the object to $objX).

So they've got to the level of Java 1.0. Congratulations!

Oh, actually, sorry, they didn't, since there are still no namespaces. But there will be soon, and then it'll be at the level of Java 1.0. Once again, congratulations!