RE: [PHP4BETA] A quick clarification question about PHP4...

At 17:11 31/08/99 , Samuel Liddicott wrote:

Thats the view of most people, its just that to some people, including me, it looks as though the wise-and-clever developers have suddenly stopped features that made it cool and popular and easy to use, and switched to measuring correctness against some arcane model appreciated by few. As I user I just want cool features, (thats why I switched to php3 from perl) I don't want them taking away. The instability of the programming interface is making me regret my change at the moment. (I've now developed whole sites around it and the change to php4 is going to be dreadful (as dreadful as the change to perl)). I really don't think the extra workload involved in converting my existing major sites (over thousands independant visitors each month for some customers) is going to be worth it. I will have to run two copies of the site, one php3 and one php4 !!! that means two copies of apache with different modules in! Agghh. I really don't think the developers have though through this restriction of features at all. That means I can't really introduce php4 to my customers any time soon at all because of the effort in simultaneously converting all my code from php3. When php3 came out with the convertor from phpfi (which I toyed with briefly) I though that it was the last of the incompatable-upgrades there would be with php. But no! And these changes aren't even for any good reason except that Zeev thinks they are not important. (And his opinion is worth a lot as it is his project) but so is mine, because I know why I use php and its because me and others use it that Zeev is even bothering with it now. So... good on you, Zeev, but please re-think this syntax changes. They really bugger up a lot of things. Cutting out backwards compatability because it isn't important to you doesn't mean it isn't for the user base. And I don't apologise for harping on; this is important to me and others who've realised what it means. More people (and I mean real users, non-beta testing type) are going to get caught short with this with little or no notice by their ISP and a lot of pain will be caused. Its best that everyone is fully aware now either to prepare, or lobby the wise-men to make the change back again.

Sam, I won't try to convince you why this change isn't only necessary, but is also more correct. I'll just say C/C++ standards are far from being arcane, they've been thought through by very very bright people, and PHP's syntax is mostly built around these standards. Now, PHP is not C, C++, Perl or Java. PHP is PHP. It borrows from the design of C and Perl, and adds in its own notion of objects. We're not committed to anybody's standards but our own. Which brings us to the variable initialization change. First off, this change is trivial to work around in userland. True, you'd have to replace a simple variable initialization with a tiny chunk of code, but that's about it. It is extremely complicated to implement initializations with runtime evaluated values. It's for a reason you cannot do that in C and C++, and generally (very generally), PHP 4.0 is similar to those languages in implementation concept (i.e. the same reasons that made it difficult to implement in C/C++ apply for PHP 4.0). We estimated the move to PHP 4.0 will be relatively painless. PHP 4.0's engine is brand new, with PHP 3.0's engine completely trashed, and fifteen thousand new lines of low level code introduced (just in the engine, Zend). Unfortunately, it's not 100.0% compatible. It's very close, but due to the radically changed implementation technique, it can never be 100.0% compatible. For you, as someone who relied on runtime initialization, the upgrade will not be painless. If it's that crucial for you that you don't think it's worth the upgrade to 4.0 - I can only say I don't think it's crucial at all as a language feature, and that I'm sorry. In my opinion, the easy (almost braindead) work involved in patching these incidents is far worth the features 4.0 presents, but it's not for me to decide. As a side note, we never intended for runtime initialization to work in PHP 3.0 either, and it's only due to our own error that it's possible to work around it. Note that in PHP 3.0, you can't do: function foo($foo=$bar) but can do: function foo($foo="$bar") Obviously, our intention was to prevent any form of runtime evaluated expressions as initializers, but we were sloppy and didn't thoroughly close that option. As a matter of fact, the reason we wanted to prevent this were technical difficulties in runtime evaluation of initializers, and there's a very very good chance this syntax causes PHP to choke or works by accident under some circumstances. I know it doesn't concern you much, but it's still worth mentioning. Finally, you seem upset, but seriously, the transition from PHP/FI 2.0 to PHP 3.0 aren't even remotely similar to the transition from PHP 3.0 to 4.0. PHP/FI 2.0 and PHP 3.0 were 100% different. As a rule of the thumb, nothing you wrote under PHP/FI 2.0 could even work under PHP 3.0. The approaches were completely different - a loosely parsed language vs. a recursive expression based language; Very loose standards for functions vs. fairly clear guidelines on how functions should behave and rules about their return values; and much more. With PHP 3.0 scripts, the vast majority of scripts will run under 4.0 without having to change a single line of code. It may be the case that because you learned to rely on runtime initialization that not a single of your 3.0 scripts runs under 4.0, but rest assured, this is not a typical example. To give you some sort of an idea, the PHP web site, Zend web site, and PHPLib, all designed for PHP 3.0, run under PHP 4.0 without a single line of code changed in them - and they include thousands of lines of 'low-level' PHP code. Again, I'm sorry you've been bitten by one of the only incompatibilities between 3.0 and 4.0, but there's nothing much we can do about it. It's not a matter of power trips on whether or not I think this should or should not be a part of the language. And finally, I'm not promising *anything*, and I mean that, but we might try to implement support for this in a future release of Zend. Don't hold your breath though, it may happen tomorrow, it may happen in a few months, and it may not happen. It's not a trivial thing to do at all, if at all feasible. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/ For a PGP public key, finger bourbon@netvision.net.il