Slashdot Mirror
PHP4.0 beta released
Emphyrio writes "Today, the first beta of Zend (php 4.0 scripting engine) was released.
Php 4.0, in combination with the Zend scripting engine, is supposed to be a faster, more efficient, and enhanced version of php 3.0.
Benchmarks between php 4.0/Zend and ASP have been made, giving _very_ good results, and showing php 4.0/Zend to outperform asp greatly.
Php 4.0 is the first public php release using the Zend scripting engine, wich is relased under the QPL source license.
More information about Zend and php 4.0 can be found on the Zend home page and the Php 4.0 homepage. . "
You are under no obligation to write bad code, and while PHP permits that, it does not require it.
I agree with you that embedding executable code in your HTML is a bad idea, unless the executable content is small enough to be trivial. PHP does not REQUIRE you to embed large amounts of code directly in your page, however. If you follow sensible Object Oriented programming techniques, you can use PHP in much the same was as Java Server Pages uses JavaBeans.
Put all of the complex code necessary for a single piece of functionality in a single PHP script which is built as a class. Pass the output of that class to a utility class, like an HtmlTable rendering class, and you only need to include a couple of PHP-specific lines in your HTML. At that point switching out the HTML becomes trivially simple. If you create a "style-free" HTML template which contains all the necessary PHP includes, then you can hand this template off to any HTML production person with simple instructions.
You still have to include SOME PHP code in your HTML - enough to point to the objects that do all of the real work, and which provide HTML output.
From the example you sited above, it sounds as though you hard-wired the PHP code into your HTML. This is a very common, but bad, practice, one which runs counter to component based development.
The website www.phpbuilder.com has some good articles discussing the use of PHP classes.
The practice of embedding executable content directly in an HTML document represents a way to share some of the development burden with people who may not be qualified programmers. You can create an object tailored to your immediate needs (business or otherwise), tell your HTML producing co-workers how to use that object on a web page, and let them do the rest of the work, while you go back to building more objects.
If you follow this practice, the graphic designer doesn't have to give you HTML templates, you can give the designer your objects, and let them build the page. Tools like Macromedia's Dreamweaver allow you to define custom objects so that your HTML people don't need to leave their familiar environment in order to embed your functionality.
disagree. major versions of important open source projects *are* "news for nerds stuff that matters". sure, you can read find them in freshmeat too, but you have to wade through 50 minor updates to random GUI CD players and the like. even if I don't use PHP (at the moment, anyway), I do want to have an idea where it's going, and the same goes for Mozilla and Zope and FreeBSD and other big projects.
The GPL was never meant to allow the original authors of the software to have any special rights over it. It's considered as a 'Copyleft' license, you're giving up all and any of your rights over the code, stating how it should be used afterwards. Moreover, the GPL is very restrictive, and would not allow PHP itself to be reused in commercial applications (since the GPL is 'contagious', if Zend was released under the GPL, so should PHP, and so should anything using it, which isn't what we want). The GPL simply isn't such a great license. It's good for many things, and bad for others. If you look around you, you'd find that great many opensource packages aren't released under the GPL, but under BSD derivatives or other opensource licenses. Ever looked at the Apache httpd license? Or MySQL's license?
The QPL was designed to be an opensource license that retains the authors' copyright over the code, while letting everybody else use it for non commercial purposes. In our case, you can use it indirectly for commercial purposes through PHP or other opensource packages that may use it in the future, but you cannot use it directly in commercial applications. For that, you would have to talk to us (Andi&Zeev) first.
That's exactly what we wanted the license to say, and we were happy to find a ready made, proof read license that is widely accepted by just about any opensource body in the world.
-- Jeff Paulsen
Take a look at the QPL 1.0, there's still a patch clause.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Why release the software under the QPL and not the GPL. PHP3 is released under the GPL, so PHP4 has to be too. Which means GPL:d software will be linked with QPL:d... Aren't the licenses incompatible?
WHY do you feel the need to post software release announcements? This is the domain of freshmeat and linuxapps, not slashdot.
Now the php site is completely unavailable, and I guarantee you most of the people going there because of the slashdot story don't use php and are just going because they say it here.
Meanwhile, the people who USE THIS SOFTWARE FOR A LIVING can't even get to the site.
Gee, thanks slashdot.
OK, Joshua's gonna kill me for this, but check his stuff:
,hacker Perl another Just)'
Hello World Benchmarks
Note that this is for a very limited test - A simple "Hello World". The idea being to test the startup time and latency only. Obviously this doesn't test the speed of database interfaces, long scripts, loops, etc. We're trying to put that right now with a sort of competition between the different scripting environment people.
For what it's worth, here's what Rasmus Lerdorf had to say about PHP4 vs mod_perl:
> keep in mind that a short test like this plays into
> PHP's strengths a bit. The larger and more complex the script is, the
> more the gap between mod_perl and mod_php narrows performance-wise and at
> some level of complexity mod_perl overtakes mod_php. With PHP4 this point
> has been moved further out to the point where the script would have to be
> *extremely* complex in order for the overall end-to-end request to come
> out faster in mod_perl. But you always have tradeoffs. With PHP you
> trade power and performance for really complex scripts for speed on simple
> stuff. That also means that the two packages can be very complimentary
> and be used together to get the best of both worlds.
>
> -Rasmus
(Hope Rasmus doesn't mind me posting this here, but it's in the mod_perl archives anyway).
- Look for new benchmarks using more real-world stuff coming soon.
Matt.
perl -e 'print scalar reverse q(\)-:
Matt. Want XML + Apache + Stylesheets? Get AxKit.
You're wrong :)
The Zend license only concerns C software written
around it. You can write and sell as many PHP
scripts as you'd like without requesting
permission from anyone!
As a matter of fact, the PHP 4.0 license is much
less restrictive than the original PHP 3.0 license
was, and much less restrictive than the GPL.
The QPL only allows us to license the Zend engine
to commercial companies, and has no effect whatsoever on PHP 4.0 nor its users.
That's simply not true. You can use GDBM and any
other GNU software with PHP 4.0, just as you could
with PHP 3.0. Even if we tried, we could hardly
mess up the PHP license that would prevent you
from using GNU software with it.
What's the effect then?
The effect is that since PHP is no longer distributed under the GPL, but the PHP license, we can no longer distribute GNU software with it, in the same package. If you obtain the GNU software in other ways (e.g., ftping it from ftp.gnu.org; GDBM was never really distributed inside PHP anyway) - you're free to use the two packages as much as you'd like. PHP 4.0 supports GDBM just like its predecessors, and there are no legal issues involved in using this or any other GNU package with it.
One last note - it is Zend that's distributed under the QPL, not PHP. PHP is distributed under the PHP license (which points you to the Zend license if you wish to see the license under which Zend's distributed).
Simply put, end users of PHP (including site builders that sell their sites) should not be concerned in any way with the Zend license. It hardly has anything to do with them. The Zend license affects mostly two groups of people - people who publish patches for it, and commercial companies that wish to write applications (C applications, not PHP applications) around it.
We'll publish a FAQ for the two licenses soon, because we see this is bothering people, when it really shouldn't.
Its like a train wreck. Stuck PHP4 on one of my testing servers, virtually none of the existing base of PHP3 code seems to work properly.
Has anyone had much luck with it?
Some code elements are obvious enough why they don't work. I'm not clear exactly why they would no longer allow non-static defaults to parameters in class constructors. Much of my code doesn't work because of that, but that can be (much less elegantly) fixed. They claim there's not very many situations where you'd want to do that, but I can think of dozens of them.
Also, PHP4 doesn't seem to like returning instantiated objects from methods in a class. I'm not clear why it wouldn't allow that, but it craps out with a parse error. Its possible that error messages in PHP4/Zend suck, as well, since that particular one isn't a documented incompatability, and perhaps its saying the error is on that line when the error is in the parsing of constructor for the object being returned.
(if that wasn't clear, code like this doesn't seem to work:)
function my_function($var = "") {
return new OtherObject ($this, $var);
}
Worked fine in PHP3. The error message sucks, so its not clear if the error is in the returning of the object, in the passing of my current object to the new object, or possibly in the constructor for the object.
Has anyone done any serious OO coding in PHP3 and had it work cleanly in PHP4? I recognize that a lot of the OO functionality wasn't documented, and should've known it could be changed, but some of this stuff isn't rocket science, and works in most other OO languages.
Anyway, good in concept, but looks like I'll be sticking to PHP3. I wonder how long development will continue on the PHP3 code base...
I'm a bit concerned about this passage in the QPL license they're using:
6. You may develop application programs, reusable components and other
software items that link with the original or modified versions of the
Software. These items, when distributed, are subject to the following
requirements:
a. You must ensure that all recipients of machine-executable forms of
these items are also able to receive and use the complete
machine-readable source code to the items without any charge
beyond the costs of data transfer.
b. You must explicitly license all recipients of your items to use
and re-distribute original and modified versions of the items in
both machine-executable and source code forms. The recipients must
be able to do so without any charges whatsoever, and they must be
able to re-distribute to anyone they choose.
c. If the items are not available to the general public, and the
initial developer of the Software requests a copy of the items,
then you must supply one.
This seems like total B.S. to me, and such a radical departure from how PHP3 was licensed, to render PHP4/Zend completely useless in a commercial environment. It makes it seem like there may potentially be a liability if an ISP is using Zend on their server, and a customer develops extensions for their website and doesn't make them freely available. There also isn't a clear distinction made between binary extensions, and external libraries of functions written in PHP.
Anyone else see this as a concern? Maybe its time to fork the PHP development, and get a similar engine to Zend distributed where that's not as significant an issue.
Its my understanding with GPL I've got every right to code a commercial non-opensource package that utilizes its functionality, as long as I either do not distribute the GPL'd software, or use it embedded into the binary form of my program? (Like the new CodeWarrior for GNU package...)