Slashdot Mirror
PHP 5 Released; PHP Compiler, Too
TheTomcat writes "After years of anticipation, PHP 5 was released today. This release represents a milestone in the evolution of PHP. It sports the new Zend Engine II, a completely re-worked object model, and many many new features. Check it and the changelog out."
In other PHP news, remote_bob writes "There have been many attempts, like
BinaryPHP
and PASM,
but finally there is a complete
compiler
for PHP. The Roadsend compiler produces standalone, native executables, and supports the entire PHP language (but not all extensions). It uses
Bigloo Scheme
to do its job, a variant of Lisp, the language that
Paul Graham writes about.
Benchmarks say that performance is pretty good. Is this another sign that dynamic languages are the future?"
...but who will use it for another year or two?
~Necromutant
This may well sever my last remaining link with Perl. While I used to ride the camel for web and shell scripting, I've now moved entirely to php for the web, and mostly php for shell scripting, with Perl used when its extra speed is useful. Presumably compiled php will eclipse Perl for scripting use now though, so (on Linux at least) I'll probably convert fully. Pity I have to stick with sed, awk and shell scripts on our old HPUX servers though...
Code, Hardware, stuff like that.
Doing PHP development has been my main source of income for a couple of years, the new release will make my life much easier, especially the new OOP model, let's just hope that web hosts will upgrade soon.
Thanks again PHP team!
The IT section color scheme sucks.
Remember, nobody's forcing you to upgrade that site running perfectly well under php4, and you probably shouldn't.
How is the cross platform ability of PHP? Can I write an app un Linux and comile and run it on OS X and Windows? Does it need a runtime, or is it bundled? Seems like an intriguing alternative to .NET.
Is this another sign that dynamic languages are the future?
I'm starting to think there are no new ideas any more, just re-hashes of old ideas. Unix, almost 35 years old, looks to be once again the wave of the future. LISP is still teaching us lessons. And the command line is still the most powerful sysadmin tool we have.
Some folks were suspicious of PHP5, and being a longtime PHP programmer, I am very pleased with the changes and additions in PHP5. Can't wait to test it out. Personally, I'm not sure if I'll use *all* of the new stuff, yet I'm sure I'll have to play with the coolest additions for the hell of it, and sort out what I'll be using and what will remain vestigial in my scripts. I will add that some of the previous PHP version quirkiness seems to be fixed.
I am certain this is not the last we'll hear about PHP5 on Slashdot, yet I am only hoping that it's creative/cool stuff, and not security problem/exploit stuff.
I can't wait to see what kinds of changes I can make to my content management system that PHP5 will bring.
The dangers of knowledge trigger emotional distress in human beings.
A good reworking of the PHP object model was definitely in order. Inheritance was a bit weird, destructors were odd to work with, and there weren't ways to declare stuff private.
The bigger question is compatibility. Will older code be ok? When will mainstream hosts migrate to the newer version? It'll be scary to find systems borken because of version updates.
As for a compiler, I'm not sure I'm comfy with the idea. Always figured if you wanted to write code for native compilation, you'd hack in C or maybe C++. Not that PHP wouldn't have its uses...as PHP is really handy and greatly increases the speed of development.
http://www.roadsend.com/home/index.php?pageID=faq
$400 for the license, which is only good for one year. After that, it won't compile until you renew.
Doesn't seem worth it for the casual hobbyist...
If speed and not closed-source is your main consideration, then how does the Roadsend compiled code stack up against interpreted code fed through the Zend Accelerator, the Turck MMcache or other caches?
mmCache is OSS and free (as in beer), which is a big plus in my book.
-Charles
Learning HOW to think is more important than learning WHAT to think.
Uhm, the compiler is priced at a low, low introductory price of $399. I don't think it'll be taking the *NIX world by storm any time soon, or cause mass adoption to PHP executables anytime soon.
Now that PHP has stopped imitating Perl, and started imitating Java, I can write some Java-look-alike code while still simple-mindedly sneering at that language as inefficient and bloated!
The compiler generates binary code that is executed directly by the CPU, avoiding the intermediate process of compiling to bytecode and running in a virtual machine
That's a true native compiler to me.
For those who are not new to php, but wan't a good primer for PHP 5 I would definatly recommend this book by George Schlossnagle. Advanced PHP Programming was recently reviewed here and it was upon reading that review that I decided to pick up a copy. It serves as an introduction to OOP to those who are unfamiliar and does a good job in covering the specific mechanics of how things operate in PHP. The book even includes some good info on some Zend Engine hacking.
Steal This Sig
PHP itself including the zend engine is 100% opensource, You can download the source you can browse the cvs to your hearts content and see everything.
The products they produce to support the development of php the closed source.
You do not need to touch, use or otherwise dirty your poor soul with any "non-free" software to use php.
There is nothing wrong with this business model, get over it.
Personal Website
I used to really be into PHP. It was great for creating a webpage in little or no time. It's syntax, while maybe not perfect, was pretty good. Until, that is, I tried to start developing my own libraries, and ran into weird quirkiness with object design, and trying to figure out the best way to do libraries, etc. It looks like PHP5 might fix the problems I had with how objects worked, and I'm not sure if it was my own fault with the messy libraries I ended up with, or whether I didn't find the best way to do it in PHP, but I eventually moved to Python out of frustration.
I had avoided Python for a long time, as I really disliked (and still do) the indentation-matters issue. But besides that, and its own set of quirks, it's a really great language, and for larger projects I have trouble even thinking about going back to PHP.
I think the biggest selling point to PHP over other solutions such as Python is that its simple. You don't have to make a whole of choices. For example, with Python you have a large number of packages to choose from: Zope, mod_python, twisted.web, Python CGI, and a bunch of variants on these. While choice can be good, it can also be overwhelming (like how do you know which package to go with until you've tried them all?).
I think I am not alone with some of difficulties I faced with PHP. So while it's great to hear that PHP has fixed many of its bugs, I think its worthwhile for people to also look at other solutions out there.
Just my $0.02.
Speaking of PHP compilers, there's a good and very affordable solution from IonCube as well.
(no, I have no affiliation to them)
...does the FBI know about this? I have heard about some of the PHP busts in recent years, but all this talk about how 'powerful' this new PHP is makes me wonder how dangerous it is. It sounds expensive, too. I hope that this doesn't lead nice young kids, into a life of crime. Imagine, hords of young, glassy-eyed kids stealing stuff like...video games and movies just to fund their PHP habbit.
Damn kids.
HA! I just wasted some of your bandwidth with a frivolous sig!
What the heck does that mean? Is that a fancy way of saying "Compiled languages"? (I somehow doubt it) What precisely is meant here? Is a dynamic language "a language that can be either compiled or interpreted"?
Honey, I shrunk the Cygwin
AUGH! And now I've violated your copyright by creating a derivative work by replying to your post without permission!
(I'll stop now. It's just too easy to make fun of the current interpretations of "Intellectual Property"...)
Hacker Public Radio is our Friend
I would prefer to say "Begun, the PHP flame war has".
For a list of PHP 5 related tutorials and articles check out this faqt or simply look around the faqts PHP 5 section.
Too late...
Hacker Public Radio is our Friend
If you'd like to see what's new in PHP 5, we got some of the leading PHP developers to write about new extensions they developed.
I also posted the first chapter of my PHP 5 book in that section which gives an overview of what's new in PHP 5. This book will be part of the Bruce Perens series of Prentice-Hall and will therefore be open-source and freely accessible to anyone.
Roadsend is a development house unrelated to the PHP development team. I doubt that their compiler would make any noticable impact since they don't support many of the PHP's most useful extensions. I have not tested it but it looks to me that the people that would be interested in this are those that want to close source their own PHP code so I guess its only fair to pay for it.
Many useful PHP tools are open source. From the bytecode compiles such as APC and MMCache, debuggers (APD and XDebug).
I see tha fact that there are some companies out there providing commercial tools for PHP developers as a good thing(tm).
LISP's parentheses turn everybody off, including me, but the data structures really are a win for tree-like applications.
Dynamic languages the future? Unlikely. The future of programming is more likely in code that isn't written, but rather "drawn"
Many people haven't heard of LabView, even though it has been around since the late 80s. It runs on Windows, Mac OS, and Linux. The premise behind LabView is there is no such thing as written code. Instead of code, applications are literally drawn by dragging variables (controls, indicators) onto the block diagram and wiring them together. For instance, if I wanted to add 1 and 2, I would create two integer objects with respective values, find the addition function, and wire them together to an output (indicator - think text box). I have written entire graphical application suites/analysis tools in a matter of days and weeks instead of months (had I written them in, say, C or Java or $your_texT_based_language_of_choice).
The only issue many will have with LabView is that it is expensive. It is also closed source, but hey, so is Java. Anyone interested in rapid application prototyping/development or digital/analog instrumentation should check out LabView.
There's certainly nothing wrong with this business model, although that's no reason to not be concerned about potential problems. As you said, they create a significant part of the core for PHP and make it open source and available for free, all of which is good. In a perfect world, this would be the perfect solution.
However, it is right to be watchful (not necessarily concerned) when the core of an open-source app is created and driven by a for-profit company. Since they sell a lot of surrounding support applications to make their money, they are clearly driven at some level to pay for that development. At the very least, it means that any really good idea that they have will get turned into a commercial product instead of rolled into an open source solution. Again, perfectly fine business model, but not awesome.
The other thing it does is that there is a subtle but probably powerful pressure pushing other developers working in the PHP space to consider not working there, because they will by definition start out behind this core company. It wouldn't hold off a determined company, but if a determined company began to come into the mix, it would be surprising if the core company didn't somehow use the fact that they are so essential to their advantage somehow. Without competition they can be magnanimous, but with it much less so.
At any rate, I'm just pointing out that there's reason to keep an eye on it, even if nothing ever comes of it. It's also important to encourage more businesses to adopt this model so something as good as this can come along, and it's important for them to be watched by others to make sure they don't abuse it. The lessons of Microsoft, although in a different league entirely, are too strong to ignore.
First of all having PCRE support and having regular expressions heavily integrated into the language the way Perl does are completely different things. So when I need to do log parsing, I do it in Perl, not Python, not PHP. It is simply easier and things fit more nicely for me (I use Python and PHP for at least as much development as I do Perl, but Perl still has its uses).
Second Perl has some nice features that PHP and Python lack. Of course PHP has some nice features that Perl and Python lack, and Python has some nice features that..... You get the point.
Even Javascript has some nice features if you are scripting other components (i.e. in a XUL application) but the next time I ask someone how to itterate through a hash table in Javascript, they had better not say "you don't..."
LedgerSMB: Open source Accounting/ERP
In almost all cases PHP4 code will run fine under PHP5.
The only situations where you're likely to hit problems are in reassigning $this in OO code, for example if you had constructors which would go
$this = new My_Error_Class();
Which is no longer supported.
PHP is dead. Long live PHP!
Now that I have that out of my system. Does anyone know if PHP5 Unicode is any better than PHP4?
Admittedly I've done about 10 total minutes of PHP coding in my entire life, but I do follow it as closely as possible when I'm not thinking about Perl. I always got the impression the Unicode working in PHP4 was a little lacking compared to the latter versions of Perl.
For example: PHP does have limited unicode support and Joel on Software.
Exactly. It's not that we always want free beer, we just like to make sure that we can drink as much as everyone else. Now, if you could request a cross-compilation for a different architecture at no additional cost with the license, then we'd all be impressed.
I guess those of us who do not know how to make our own binaries just have to wait for Marc Liyanage to port this thing.
thanks Marc.
I cant wait to play with the final XML/DOM-3 libs.
...but Microsoft really did get there lightyears ahead of this, with a far more complete class library and a standardized language, as well as a scripting engine that supported true seperation of code, presentation and so forth.
Just to clarify this, consider the following:- ASP.net's been precompiled since the 2000 beta, and it's been production ready for years. The C# language is also fully documented and is a public standard ratified by the EMCA.
PHP5, however nice, is treading old water, and in terms of functionality is still lagging behind even Java/JSP. The whole reason I'm assuming people stuck with PHP4, rather than move to something more robust that provides this kind of capability, is that:-
1) They're apathetic about new technology.
2) If the old language does what they want, why upgrade. It's *Personal* Home Page, after all, not corporate homepage.
3) Why make things more complex, for very little benifit.
Performance wise, the compiled version advantages are fairly insubstantial, and 99.9% of the new stuff they've added could have been done in other ways using the existing language.
The whole thing seems pretty stagnant, and I'm guessing there's a small chance that the PHP guys are stuggling to find their own space between the land of true pre-compiled OO languages and the interperated world that lay behind it.
I've worked with PHP4 and ASP.net since both of them were betas, and if PHP wants to be a serious consideration for large scale development, it'd better decide which side of the OO fence its on, and stay there.
This makes me wonder if the PHP programs have to be manually compiled, if they can be compiled JIT, or if a compiled version can be cached and only recompiled if the original PHP source changes....
Ok, apart from the fact that you're obviously trolling, I don't really have a comment on most of your points as I've never used ASP, and I've used PHP enough to know that I hate it and everything it stands for, but I still have to question at least one of your points - "ASP includes database connection pooling, something that costs many thousands of dollars on Unix"
That sounds like you're quoting a marketing guy with no idea what you're talking about.
Sure, ASP may contain DB connection pooling, and sure, PHP may not have it, but "Costs many thousands of dollars on Unix" is the most ridiculous thing I've ever heard.
Show me this many thousands of dollars worth of "Database Connection Pooling On Unix".
Unix has nothing whatsoever to do with it. PHP runs in IIS quite nicely. And even if PHP was a Unix specific thing, there's nothing hard or expensive about connection pooling, and there are free libraries implementing it in just about any language that can access a database.
Advanced users are users too!
(Hurray for being modded as flamebait!)
In my experience, the memory management in PHP is not good. Coding should be very careful, or the memory will be usually exhausted.
Another problem is the speed. Well, it is inevitable that interpreter execution is slow. However, I think PHP can run at least twice than current version if the inner architecture of PHP could be carefully rewritten.
Additional, I hope PHP could be multithreaded. When develop a serious application, multithreading or multitask can help programmer lots. And also the efficiency of application could be higher.
I hope these problems could be solved in PHP 5 or later versions.
If you are interested in apia, check : http://clonefab.net/, but there is no English web site yet, sorry for this. It is developed in Chinese language initially. The English document will be ready ASAP. As for apia package itself already support english. You can download it in : http://clonefab.net/apiaDownload.php
With your reasoning, there's reasons to be concerned about every open source software except those created in the basements of college dorms.
Frankly, I don't disagree with you. You should be mindful of every piece of software you use, open or otherwise. But, your argument seems more about Karma Whoring than it does a real concern.
I mean, seriously, what about the Apache Foundation? Where do you think they get their money from? Corporations using their products, right? Don't think they're influenced by said corporations?
I frankly an very supportive of the Zend model of creating a business around open source. It's very pioneering, they've done a good job. I've used php since the PHP/FI (v2) iterations, and I'm still happy to continue using it.
Beware of geeks bearing formulas.
A lot of folks have no problem migrating from f(a, b) to (f a b). In fact, a lot of people don't find the migration from 2+2 to (+ 2 2) all that hard. I use Scheme all the time and like it.
Is php 5 thread safe? More specifically, is it safe to use in a production environment with Apache 2?
Its definatly an awesome release. I'm thrilled by the native SOAP support.
Hard to imagine what the OS crowd will do with a blockbuster feature like this generally available. SQLite will improve the xcopy deployment compatibilities of simpler apps and SimpleXML is the best xml API i have seen so far in any language. On the OOP front we get exceptions which will finally unmangle the error systems of most complex php web apps which usually accounted for a big chunk of the code.
Anyways, php is cutting edge again.
As a long-time PHP developer, I have to agree with you somewhat. PHP5--Woohoo!! Ohh, wait... No namespace support? (Arggh... of all features to leave out...)
;), but at least PHP puts them all together easily at your fingertips.
All the new features are sort of the stuff you would call a 'given' for object-oriented programming. Nice to have, but nothing to get really excited about.
Really the things that I found more interesting about PHP were all the system-oriented capabilities developed from version 4.3 onward, such as streams, sockets, direct I/O, etc... Of course, all these are givens in some languages too
The other cool things about PHP are the really dynamic things you can't do in Java, such as variable variables ($$varname), variable function calls ($function_name()), and the extended features for variable interpolation in strings. Also, features like array_map, create_function, and the overload extension are quite cool.
But yes, it looks like Perl 6 is going to up the ante big-time. Interesting to see where PHP goes in the interim, though.
I see so many posts about how this would make them switch from perl to php.. but perl has had this for ages...
http://www.indigostar.com/perl2exe.htm
http://par.perl.org/
HEH!!!
...but for some reason I'm rather disinterested.
Don't get me wrong; I've been doing PHP coding for a while. But the fact of the matter is that the more I code in PHP, the more I dislike it.
Granted, the new OOP features in PHP5 are a good thing; hell, they should've been in there a LONG time ago. And exception support has me jumping for joy.
But where for the love of all that is holy is support for namespaces? I mean, sure PHP has a ton of really handy extensions, but I am getting so sick to death with typing underscores that I'll be happy man if the world suddenly decided that underscores were bad and removed them from all character sets (oh, and keyboards) entirely.
And I've also come to the conclusion that the standard PHP api can't quite make up it's mind whether it's supposed to be emulating C, or maybe some other language. Some array functions are prefixed by array_. Some aren't. Some have their arguments in the reverse order that almost all the others do. It's a mess.
PHP is a nice language, good for beginners. But it's complete lack of namespaces, half-arsed support for functional constructs (damn I hate having to write callback functions out seperately when they're one liners!), and schizophrenic api are slowly pushing me towards more well thought-out languages like Python.
Sure, Python's "thou shalt indent" system annoys me a lot of the time, but other then that it's just a clean, logical language. Unfortunetly, support for it on web hosts seems to be all but non-existant.
Seriously, if the PHP devs really want to bring PHP up a few notches, they need namespaces, and to standardize the API naming conventions. I shouldn't have to constantly open up the PHP manual to work out whether the array sorting function has array_ out the front or not.
Still, it's a nice set of improvements, so credit where credit is due. Kudos to the PHP team.
We're geeks... We're the sorcerers of the modern-day world. --
Uh... no. They also changed the object inheritance rules so that overloaded child methods have to have the exact same number of parameters as the original class. So, now you can't have multiple constructors *or* have child constructors that assume certain values and reduce the amount of paramters accordingly.
Yuck.
As a person who codes entire 20,000+ line application libraries in PHP and has been watching the development of PHP 5 very closely, there are a lot of decisions the PHP developers have made that make me very hesitant about going anywhere near the new PHP version.
As an aside, the PHP developers have decided to make SQLite, a light file-based database engine, the default session handler. Even with all file locking turned off, this is at least 4 times slower than the current system used by PHP 4. Of course you can change this setting back to flat session files, but the fact this is their default should say something about other decisions they've made. This setting itself makes especially no sense to me, as all session variables go into the $_SESSION superglobal as associative array keys - there is absolutely no benefit to using a database-enabled flat file for this, as opposed to a regular flat file. It's as if the PHP group were excited about sqlite and tried shoving it into everything.
Just read the changelog very carefully. If you're already using PHP, and have gone deeper than casual use, your applications *will* break - especially if you turn on PHP's strict mode which kills backwards compatibility with PHP 4.
Read: Rabbit Rue - Free serial nove
The basic summary is, PHP does not support Unicode or any other encodings properly. PHP strings are 8-bit-per-character and do not have any explicit encoding. Sure, there is a multibyte string extension available, but when you look at the big picture, it's worthless.
/maybe/ the popular graphical extensions like GDlib). Which means that for those developers, PHP does not do Unicode at all.
The reason is that PHP's biggest strength is that these days, you can get a PHP-enabled host for virtually no money. However, most of these installs run a standard PHP, some even a locked down one.
The consequence is that anyone who wants to develop PHP software for a large audience cannot use any non-standard stuff (except
I don't see why they won't do native Unicode, when Perl, Python, Java and all the other popular web languages support Unicode with all the bells and whistles.
Benchmarks say that performance is pretty good. Is this another sign that dynamic languages are the future?"
No more and no less so than they have ever been: dynamic languages are a good choice for many, but not all applications. And dynamic languages have been enormously popular for decades, with far programmers using them than using static languages; PHP just follows in that tradition.
What is more interesting is the emergence of dynamic languages which use static type systems by default: in their runtimes, Java and C# have more complete and better defined dynamic features than Lisp, but they still give the user a simple static type system by default. It remains to be seen whether that gives you the best of both worlds or the worst. Fortunately, their runtimes are well-defined enough that one isn't limited to the specific choices that the currently popular languages running on top of them have made.
-- . . ramblin' . . .
Lucky PHP guys.. Too bad that support for compiling Perl code into executables is almost non-working.. The only viable alternative I know of is using Stunnix Perl-Obfus for obfuscation/scrambling, and turning output into executable with PAR or Perl2Exe. Does anybody knows a better alternative?
$ rpm -qlp roadsend-pcc-prereqs-beta2-1.i386.rpm | grep bigloob /bigloo/2.6c/ lib/bigloo/2.6c/bigloo.heap/ bigloo_config.hc .sog loofth_s-2.6c.so
/usr/lib/libbigloogc-2.6c.so
/usr/bin/bigloo
/usr/lib/bigloo
/usr/li
/usr/lib/bigloo/2.6c/bigloo.h
/usr
/usr/lib/bigloo/2.6c
<snip>
/usr/lib/libbigloo_s-2.6
/usr/lib/libbigloo_u-2.6c.so
/usr/lib/libbi
/usr/lib/libbigloofth_u-2.6c.so
/usr/lib/libbigloog c_fth-2.6c.so
...Dmitri who wrote Turck mmcache was offered a job at Zend and, shock horror, took it. However, as mmcache is GPL'd it lives on at sourceforge, with a new cvs commiter appointed (IIRC) and dev work continuing. To be honest though, it's pretty much feature complete so all they need to do is sure up support for PHP5 (still beta at the moment).
I am NaN
i'm not quite sure where you're getting this from.
/* outputs:
i've been using php5 since the first beta and afaik it has never required overloaded child methods to require the same number of arguments as the parent class.
<?
error_reporting(E_ALL|E_STRICT);
class SomeParent
{
function __construct($var1, $var2)
{
echo "Parent: $var1, $var2\n";
}
}
class SomeChild extends SomeParent
{
function __construct($var1,$var2,$var3)
{
echo "Child: $var1, $var2, $var3\n";
}
}
$x = new SomeParent(1,2);
$y = new SomeChild(3,4,5);
$z = new SomeParent(6,7,8);
Parent: 1, 2
Child: 3, 4, 5
Parent: 6, 7
*/
?>
as for sqlite as session handler, it is not the default, nor has it ever been the default.
there was a patch to ALLOW it to be used as a session handler, by setting session.save_handler = sqlite in php.ini
but if we look at the php.inis in the php5 distribution:
[solidox@server150 php-5.0.0]$ cat php.ini-*|grep "session.save_handler"
session.save_handler = files
session.save_handler = files
both dist and recommended use flat files as the default session handler.
If memory serves, PHP3 had built-in debugging output capabilities. When Zend became 'official' and PHP4 was released, debugging was suddenly nowhere to be found. BUT, lo and behold, you can get debugging capabilities if you purchase the Zend Studio and server extensions. Yes, there are open source debugging extensions now too, but that move was the one that made me start thinking like you're doing. Again, nothing inherently WRONG with it, but it was something that seemed to be held out of the core system to help fund the development by selling it separately.
creation science book
Have they fixed the most annoying thing about PHP4? Specifically, if I put <?xml version="1.0" encoding="iso-8859-1"?> quite normally outside of PHP code, PHP4 barfs. (Which is quite annoying if the recommended way to put PHP code in is to use <?php ... ?<, specifically for XML/XHTML compliance. A savage hypocrisy.) And before you ask, no, I can't mess around with PHP configuration or anything.
Also, what about componentization? Any news on that front? I'm quite fond of Perl's HTML::Mason and sort of like JSP tag library ideas - can I clearly separate the code and the page, or do I still need to mess them together?
News of a new XML parser sound good, though. PHP4's idea of XML parsing is... ugly. =)
I remember putting a CMS together with PHP4, something like Midgard, but pure PHP with multiple backends. It's not entirely a bad design even now, though I think Zope has a better answer.
... which did exactly the WRONG thing and implemented even DEEPER comparison. That was the point where I went over the edge and wrote off PHP. I hear this behavior has mercifully changed to a sane one in PHP5.
I ran into some awesomely dumb stuff. I mean "what are they smoking" stuff.
Brain dead parser: First of all, this requirement to put everything in tags or whatever brackets you have defined. What is this, javascript? (and even javascript doesn't need it if you use src="foo.js"). That alone, not so bad, but the parser would easily choke on any end bracket construct ANYWHERE -- in a string, in a comment, etc.
Flat namespace. OOP completely unused in extensions. Since PHP can easily call functions dynamically by name, and we have PEAR now, I consider the problem solved. No worse a hack than perl's OOP implementation, really. But I had other problems with OOP...
Pass-by-value: PHP4 would pass objects by value. Which is actually great if I want such value-type, but 99.9% of the time, I don't. What made matters worse was PHP's twisted notion of object identity -- it had no operator to test it. Equality comparison operators were always by value, and either "shallow" or "deep". I had to explain the concept of object identity, and for my trouble, got the '===' operator
Second-class-language attitude: I got choice responses from Zeev himself about how PHP is never intended to be more than a "web language" (apparently meaning limited to trivial scripting, because the web apps I use sure aren't trivial). PHP can be and has been used for powerful things, but I don't see writing a caching bulk DNS lookup service that tests against multiple RBL's using PHP if I can't get a serious contender to Net::DNS because PHP is "merely a web language" after all. I used Perl for that, then switched it to Python (stackless was ideal for this job) and then dropped it into the object publisher in mod_python. Painless. There is no such thing as a "web language", behind every web app there should be a *real* language.
Error handling: Nonexistent. Got an error, it would print a traceback to the output if you were lucky. Syntax errors would simply die without any useful diagnostic. No eval (well there is, but it would also just die on syntax errors). I've seen structured exceptions in C, but PHP's was awful. Awesomely brittle.
Hopefully PHP5 is migrating most of these warts away from PHP4. Perl certainly still has its own problems (mod_perl 2.0 is still not in a stable release state) so it's not too late for PHP among current perl users.
I've finally had it: until slashdot gets article moderation, I am not coming back.