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

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?

[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?

[ajagci]

The vast majority of things that closures would be used for can be done with "eval()" and "execute()" like functions that evaluate in context.

Closures aren't "used for anything", they just give the language straightforward and sensible semantics, as opposed to the mess that results when you name functions by strings, like PHP does.

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.

What does dynamic execution have to do with resolving variable references correctly?

Closures just tend to frighten away people from a language. Closures == "those damned math nerds got their fingers into it" :-)

Actually, if you are talking about impressions, the main impression the current language leaves is that the PHP language designers just don't know what they are doing. There is no conceivable technical or practical reason for not implementing lexical closures correctly.

Very easy to learn if

[Anonymous Coward]

You know C. I never "sat down & learned" PHP - a coworker told me how to use echo (and print_r() for arrays, etc), and how to do open tags ... and the rest "just worked", as they say. Oh, that plus www.php.net's function search ... um ... function ... helped.

Half of it is just learning database usage; the other half is knowing C-style (C/C++/C#/Java) syntax, and it really shouldn't be hard to adapt to even if you're not familiar with any of those.

The best part is that you can even use it on a server to write scripts (logging, etc., w/o a mindset shift). Or that no plugins are needed b/c it's server-side.

Yes, I'm a fanboy. But it deserves it.

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.

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:Don't forget to check Zope

[geoffspear]

You know a markup language (DTML) is horrible when the people writing the documentation repeatedly tell you not to use it right there in the middle of the documentation, but to write Python scripts instead.

Re:The superiority of PHP over Pearl

[Tablizer]

php has no real threading support e.g. other than simple webscripts are impossible to create

What is an example of such need? Web-based interfaces generally don't need that kind of multi-threading.

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

Php philosphy is generally to use the database for shared information, not RAM. If you want an "enterprise" application, then get a big-iron RDBMS like Oracle, DB2, etc. to use with Php.

even the new php-s oop structure is still out of date...

Again, Php tends to use the database for "noun modeling" instead of OO. Thus, it tends to de-emphasize OO. If you are an OO affectionado, then Java will make you happier. Relational thinking and OO thinking tend to collide in Philosophyville. Php tilts toward the DB side.

Re:No upload progress support in 5.0

[Anonymous Coward]

It tells you something that PHP coders are crying for upload progress bar, while environment lacks basic appserver features like connection pooling.

PHP docs...

[scott_davey]

I think PHP's documentation has a mix of good and bad.

The function reference is usually quite good, and the contributed comments make a good reference excellent. It could be further grouped to become easier to navigate, grouping all the "database access" functions together in a deeper heirarchy, for example. (PHP in general is suffering from having too many functions IMHO - that may be fixed in PHP5 though).

However, the language reference, which is intended as an introduction to the language, is not great for beginners. It definately needs tutorials, and a quick reference to common functions used in real-life scripts. An overview to accessing a database would be good in here - connecting, fetching, resource handles, etc - rather than having to go to the function reference and guess the functions you might need. Also, it could contain a language-to-language comparison of commands and concepts to entice ASP/PERL/Python/LanguageX programmers to easily convert.

I can see that beginner programmers, or PERL/Python/LanguageX converts, would find some troubles coming up to speed quickly with the launguage based on the current manual. But as a seasoned PHP programmer I now find it is a great resource.

I agree with the parent poster that the user contributed comments are essential in understanding some functions, and this probably highlights some deficiencies in the manual. But the fact that a good community exists to add these comments, plus the manuals ability to store them, makes for an excellent resource.

All in all, I think the PHP development group is doing a great job, and I look forward to PHP5 (well, perhaps 5.02 :-)