PHP5 Just Around the Corner

HitByASquirrel writes "Just doing the rounds and I found that Zend has released PHP 5.0 Beta 4: 'This fourth beta of PHP 5 is also scheduled to be the last one (barring unexpected surprises, that did occur with beta 3). This beta incorporates dozens of bug fixes since Beta 3, rewritten exceptions support, improved interfaces support, new experimental SOAP support, as well as lots of other improvements, some of which are documented in the ChangeLog.' Hopefully they won't have any 'unexpected surprises' and we'll see this before summer!"

Comments

Re:The superiority of PHP over Pearl

[moro_666]

php might be a simple scripting language easy to
use but,

just wanted to point out :
1) php has no real threading support e.g. other than
simple webscripts are impossible to create
2) using whatever wierd forking in your php scripts
still leaves you without shared variables and so on.
3) php has still very slow interface to shared memory
(shmop), which makes it even more pointless to use in
real enterprise applications even for web
4) even the new php-s oop structure is still out of date
when compared to java or c++ or even perl (where are
protected variables and callbacks? why does the php still
not have a normal automatic class searching system and
still relies on user own written inclusion lines? etc.)
5) php developers are heartlessy disgarding every kind of
backward compatibility with every new minor version they
write, e.g. your old scripts which worked finely for 4-5
months may be buggy without you even knowing it after 1
mysterious update.

just wanted to make this statement. php has still a long
way to go to make it to the real enterprise market where
perl and java are already ready. the new version of php
doesn't include any major necessary components to achieve
the raise to real enterprise developement market.

still hope they will make the jump to real applications
cause the idea of php is quite good. only the
implementation needs be improved. php6 maybe ?

Why no lexical closures?

[ajagci]

Does every little scripting language have to repeat the same mistakes? Lisp 1.5 thought it could get by without. Perl did. Python did. Lua did. In the end, they all added them.

Come on, guys, learn something from history, avoid making the same mistakes over and over again, and add lexical closures to PHP.

Re:Why no lexical closures?

[FrangoAssado]

Well, for a quick and simple example, instead of writing

function f($a, $b) { return strcmp($b, $a); }

usort($array, 'f');

you could just write something like

usort($array, function ($a, $b) { return strcmp($b, $a); });

With this, functions would be first-class objects, which probably complicates the internals of the language, but it could be added when the reestructuring for improved OOP was done.

Re:Why no lexical closures?

[gid]

So what's the matter with doing it the old way?

Maybe I'm missing something, but it seems defining the function inline makes the code less readable, and more cluttered. PHP isn't really about being able to mimick the perl one line "goodness". Written properly, php code is very readable and easily maintainable. If feel that's one of the major reasons for it's popularity.

That and the low learning curve and excellent online docs. I have a one stop shop for php documentation. I rarely need any other docs besides php.net/searchstring

Re:Why no lexical closures?

[Tablizer]

The vast majority of things that closures would be used for can be done with "eval()" and "execute()" like functions that evaluate in context. Although they may not be as "clean" as pure closures, eval and execute are conceptually simple and will do the job for the occassional times dynamic execution is needed. Closures just tend to frighten away people from a language. Closures == "those damned math nerds got their fingers into it" :-)

PHP5 References

[djace]

Yeah, sure, "just around the corner". That's what they said a year ago :P

Some interesting slashdot PHP5 references:
"PHP5 is well under development and a beta is expected out by March 2003 and released summer 2003"
Introduction to PHP5

General PHP5 References:
Changes in PHP 5/Zend Engine 2.0
Pidget: The PHP Widget Library

Re:The superiority of PHP over Pearl

[Michalson]

5) php developers are heartlessy disgarding every kind of backward compatibility with every new minor version they write, e.g. your old scripts which worked finely for 4-5 months may be buggy without you even knowing it after 1 mysterious update.

That has to be the absolute worst. Not only do the minor versions break large numbers of scripts, they do it for the sillest reasons - php has some incredible powerful and language changing options (like magic quotes, which entirely change how you handle input), yet they insist on changing the defaults for these every time they increment a number. The real business world doesn't have the time and re$ource$ to be constantly updating code and mangling configurations just because some open source team can't make up their mind.

Re: PHP and Backward Compatibility

[Paul Burney]

You said...

5) php developers are heartlessy disgarding every kind of backward compatibility with every new minor version they write, e.g. your old scripts which worked finely for 4-5 months may be buggy without you even knowing it after 1 mysterious update.

Thank you for bringing that up. That's been my biggest complaint with PHP. Some examples include:

• redefining the way that strtok works
  
  
• changing the syntax for the deleting cookies without mentioning it in the change log or documentation (for 3.1 - 4.someting you could just call setcookie('variablename','') to unset the cookie. They switched it so you needed to add all the parameters to the function call, date, server, path, etc.)
  
  
• breaking the error_reporting() function for several versions, forcing users to rewrite their calls using ini_set() instead.

It seems that any time there is an update for PHP, something else gets broken. I cringe when my sys admin tells me he wants to update it, because I know it's going to lead to hours of debugging work that I shouldn't need to do.