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 ?

No upload progress support in 5.0

[dostick]

The much-requested feature of Upload progress did not make in PHP5.0
Too bad. Now we need to wait until PHP5.1 or something.
And meanwhile stick with PHP sourcecode patch or perl method which is nightmare.

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?

[scrytch]

<? function a() { echo 'all work and no play makes jack a dull boy '; a(); } ?>

The question is, does PHP have tailcall elimination, or does jack blow the stack?

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" :-)

Re:Why no lexical closures?

[ajagci]

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

The matter is that (1) you are referring to functions by their name, not as an object, and (2) that you can only write functions that refer to global variables.

Maybe I'm missing something, but it seems defining the function inline makes the code less readable,

Lexical closures have nothing to do with whether the function is written in-line or not. It has to do with functions being data objects rather than strings, and it has to do with variables being resolved correctly.

Just think about this snippet for a moment:

function mysort($array,$direction) {
$compare = function($a,$b) {
return $direction * strcmp($a,$b);
}
return usort($array,$compare);
}

That's how things should work.

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.

PHB

[bayankaran]

Is it only me...I read 'PHB just around the corner'.

Re:Will the docs still be full of Perl envy?

[scrytch]

In summary, the documentation is so bad, I can't even make a decent evaluation of whether the language is any good. The *first* thing the PHP crowd needs to fix is the documentation. It ought to be rewritten from scratch.

I have experience with both PHP and perl. I have a raging bias against PHP, but I'll try to tell it straight:

PHP's a lot easier to install than mod_perl, full stop. That is to say, mod_perl might be a package install away, but configuring it to get its features working takes some work with trial and error. By being essentially an embedded evaluator first and foremost and last, PHP doesn't confuse you by dealing with apacheisms like request handler objects. Of course it doesn't confuse you with having any real general-purpose functionality either (I'm told there's actually a gtk binding, but I can't seriously consider this as more than a toy).

PHP's syntax is more regular and reduced than perl's. It has only one sigil, $foo, as opposed to $foo @foo %foo and $foo. It lacks most of the line noise constructs like $#foo. References are managed internally (though you must explicitly pass by reference to functions) so there's no difference in syntax between an array and a reference to one. PHP5 will pass objects by reference by default. PHP4 always passes a copy unless you explicitly pass by reference. I found this to be really quite a misfeature in PHP4 that I'm happy to see fixed. I certainly hope the === operator has its extremely broken semantics fixed (it does the deepest of comparisons instead of the shallowest) but I'm not holding my breath.

PHP doesn't auto-splice lists. In fact it doesn't auto-create them from the various contexts perl does, you must use the "array" function to get a list. One gets used to this, and ultimately it's not much worse than lisp's list function. Arrays are much like lua arrays, and can have numeric or string keys, there is no separate "hash" type or hash syntax to go with them.

PHP4 has no structured exception handling at all. In fact there's no mechanism whatsoever to trap many errors that simply result in a dead stop of execution, with an error message if you're lucky, otherwise no response whatsoever, more akin to a killed CGI. Older PHP4 scripts are rife with uses of automatically populated global variables that make them targets for cross-site-scripting and sql injection. Don't trust a PHP script from before 2002 or so. PHP5 is supposed to address these issues.

Don't forget to check Zope

[axxackall]

Just for a case if there are people here who don't know about Zope but who are tired from primitivenesses of PHP and who would be interesting in migrating to Zope from PHP:

There is much better alternative to PHP. It's called Zope. In fact, Zope has two similar (but very superior) markup languages: DTML and ZPT, both using Python for underlying scripting.

Just go to the site and check brief functional description - you will be surprise how far their technology has been developed for the last year.

Personally, I was developing on PHP before (like SquirelWebMail plugins, database applications), but I don't see any reason to write PHP anymore. All my current and upcoming web-projects are only Zope-based.

Re: PHP and Backward Compatibility

[timothv]

Just as an example as to how backwards compatiblity should work, Python has it about right.

For example, the current python version returns 2 when you type 5/2. In Python 3.0, the behavior would be changed to returning a float (2.5).

This could break plenty of scripts, such as parse_lines(file_size/2) where the argument could only be an int. Now, to the magic:

These future changes are announced years before the actual forced change in the language. However, for your current Python 2.3 program you can import future behaviors, like so:

from __future__ import division

Which will make sure that your division doesn't break once python reaches 3.0.

Re:How Much?

[Angst Badger]

How much will it cost for the add-ons necessary to run PHP on a high traffic server? You know, the cache that should be included in the base product but isn't because it would hurt Zends market.

There are several free third-party caches that work just fine. The PHP folks even provide links to them.

That being said, I work for a company that has a high-traffic site -- about 3 million page-views per day, and we run it without a cache. It takes eight load-balanced web servers to do this, and the main bottleneck is response time from the MySQL server. (This is not a slam against MySQL -- it's chugging along at about 10,000 queries per second.) We could get by with less hardware if more non-sensitive data was shoved into cookies instead of the database and more trivial UI stuff was migrated to client-side Javascript.

PHP's main problem, in terms of implementation, is that it's a bit of a memory hog. There's a huge amount of metadata that goes along with PHP variables, and a PHP array of n elements consumes several times as much memory as the equivalent Perl array. If this has been addressed in PHP 5.0, it will be a big damn deal.