Slashdot Mirror

Any tendency to optimize prematurely ought to be avoided, at least until after v1.0 ships.

Assuming there is a second version, which there may not be because potential customers found that the performance of v1.0 sucked.

I wrote an application not too long ago. Being that PHP is my language of choice, and being that PHP-GTK was available, I wrote it in that language.

The software manages paperwork for schools. There are about 1,000 courses in files in the program. The user selects courses, gives assignments to students, grades the results, and prints it off.

I initially paid no attention to performance - and performance sucked. It would tie down a P4-2000 badly in places.

So, I spent a week or two optimizing performance. I discovered a few things about what really slowed down the computer, and built indexes in memory rather than reading from disk anytime you "want to know".

Bottom line is that it's a terrible performer for performance. Just pitiful. It's also completely irrelevant since the average user has about 800 Mhz system, on which it performs just fast enough to never appear slow.

And, in a few years, it'll be "lean and mean" compared to whatever else is out there.

Oh, and version 1 (called 4.0 for largely historical reasons - it's a rewrite of an earlier, fundamentally broken codebase) has been quite successful, and I'm in the middle of pounding out version 2 as quick as I can.

Too bad your post wasn't modded up, I was about to re-type what you said. They make a BC version for windows as well. Can't find the link right now but search for "BC.exe". Also, PHP has a "bc" function.

After that, it depends on my OS. For most of the Linux installs I do, the next few things I install will be MySQL, OpenLDAP, Apache, and PHP, which takes care of most of my needs. My Windows box (which, I admit, I use at home) is a little more fun:

2. iTunes
3. Whatever freeware Shisen-Sho app I can find
4. Starcraft
5. Several games later, OpenOffice.org

Let's be honest: does a computer really need anything else? I certainly don't think so.

• gentoo linux
• FreeBSD
• bash
• vim
• perl
• ruby
• MySQL
• PostgreSQL
• Apache
• PHP
• links www browser
• wget
• K Desktop Environment
• Mozilla Firefox
• xchat
• gimp
• Openoffice.org

I thought it kinda odd about ini_set. This page describes the various variables PHP uses and where they can be set (my mistake not for not reading it properly).

-h3

So you're saying it's a language feature aimed at helping newbies producing mediocre code.

magic_quotes_gpc is dangerous, in that it confuses said newbies horribly about a critical issue. They may be producing mediocre code where they would have been producing bad code, but it will lengthen the time until they learn to produce good code. Or maybe prevent them from ever doing so!

• When newbies see words like "magic quotes", they may think "okay, everything's quoted and safe". When it's not nearly so simple.
• A feature intended to help people mix untrusted data into SQL statements suggests that it is a good practice to do so. It's not! It's much better to use bind variables.
• It increases the operating modes a program executes in. Take a look at this bit from the get_magic_quotes_gpc section of the manual:

  if (!get_magic_quotes_gpc()) {
  $lastname = addslashes($_POST['lastname']);
  } else {
  $lastname = $_POST['lastname'];
  }

  They're promoting the idea of having the same program work in both modes. Do you think people extensively test both? It would be much better to say "loudly fail if your program is not run in the expected mode". Hell, they're not even doing this in a general function; they're proposing doing that for each variable reference! That's stupid! People will inevitably write code that works in one mode or the other. Seeing this pattern elsewhere in the code will falsely lead people to believe the entire thing works in both modes.
• With this "safety" feature on, truly safe code would be much more complicated than without, and this is never stated in the manual. The correct way before was to "escape stuff in way X right as you use it in way X". Now it needs an addendum: "except if it's from a GET/POST string and it's to a MySQL or PostgreSQL database literal. and when you use GET/POST strings for anything else, strip off the slashes first." That's complicated enough that a newbie may never learn the correct way of doing things in any mode. They'll always think it is too complicated to really understand, always be tinkering, and always screw it up.
• it makes people have some data floating around that should be treated quite differently depending on where they got it. If they get it from the database, it's not escaped in a similar way. Do you think they'll keep rigorously keep track of every string being passed around and state and follow a contract for how each function's arguments should be quoted? (And yes, there are valid reasons for getting something from the database and sending it right back.)

By the way, you mentioned stripslashes. I'd argue that any use of stripslashes means that you've screwed up and escaped something badly. If something has slashes, it's intended to be parsed through a layer that mixes strings and some higher-level construct. So when you strip them out, either:

• you're writing a parser that doesn't know the length of the string until it's done. It'll be appending to the string as it goes. stripslashes doesn't help.
• you've got something escaped in the style to send it through a layer you actually aren't using. You're escaping something at the wrong place in your code. If you haven't already screwed it up and introduced a security problem, you soon will, because your function's contracts are too confusing.

The PEAR DB package has a function called quoteSmart() that does something like this. It's what I use (and PEAR DB is a great database abstraction tool, by the way.)

The PEAR DB package has a function called quoteSmart() that does something like this. It's what I use (and PEAR DB is a great database abstraction tool, by the way.)

This is not an issue dealing with PHP and MySQL, this is an issue with weak programmers writing bad code, and I'm sorry to say, you find it in every language. As a regular in #php on freenode, we are constantly correcting bad coding practices.

In fact, it's not uncommon to find people using GET and POST variables straight out of the box without any kind of validation whatsoever. Many people do not learn the de-facto first rule of web programming: the user can not, and should never be trusted.

To make matters worse, applications like PHP-Nuke spring up which are notorious for sloppy coding practices, and people tend to see them as reflect on the PHP community as a whole. That's like blaming the C language because someone, one day, wrote some bad code in it that got someone else hacked. This happens all the time, but we don't make claims like "C security is weak". Instead, we worry about the truth of it, that the programmer in question did a bad job, or just flat out missed something.

One of the key points that seems to trip most novices up (and granted, this is one of the stupider moves presented by the PHP Core Development team) was a thing called magic_quotes_gpc, which attempts to auto-escape incoming GET, POST and COOKIE variables in an attempt to sanitize user input. This is usually a double-edge sword because newbies are typicly not aware if it is, or isn't on. In later versions, this is on by default, and does prevent many SQL injections from occuring. However, for the more experienced user, having your input auto-munged can be something of a pain. Unfortunatly, to write truely portable code one must test this value and normalize data accordingly.

The issues don't stop there though. I've seen many a more serious faux pas committed by the newbie. Another more serious flaw that I see happen on a regular basis is the use of user data within include statements without proper path checking. This is probably one of the more disasterous errors I see occuring because it typicly exposes sensitive data. There has been more than one occasion where i've shown a user their own passwd file in a browser to make my point.

Anyhow, to the newbies: we, the more experienced people of PHP are on our own quest to educate people, many times in a one-on-one basis on Freenode. If you're not sure about a particular issue, grab an IRC client and ASK US (irc://irc.freenode.net). We're there to help!

This is not an issue dealing with PHP and MySQL, this is an issue with weak programmers writing bad code, and I'm sorry to say, you find it in every language. As a regular in #php on freenode, we are constantly correcting bad coding practices.

In fact, it's not uncommon to find people using GET and POST variables straight out of the box without any kind of validation whatsoever. Many people do not learn the de-facto first rule of web programming: the user can not, and should never be trusted.

To make matters worse, applications like PHP-Nuke spring up which are notorious for sloppy coding practices, and people tend to see them as reflect on the PHP community as a whole. That's like blaming the C language because someone, one day, wrote some bad code in it that got someone else hacked. This happens all the time, but we don't make claims like "C security is weak". Instead, we worry about the truth of it, that the programmer in question did a bad job, or just flat out missed something.

One of the key points that seems to trip most novices up (and granted, this is one of the stupider moves presented by the PHP Core Development team) was a thing called magic_quotes_gpc, which attempts to auto-escape incoming GET, POST and COOKIE variables in an attempt to sanitize user input. This is usually a double-edge sword because newbies are typicly not aware if it is, or isn't on. In later versions, this is on by default, and does prevent many SQL injections from occuring. However, for the more experienced user, having your input auto-munged can be something of a pain. Unfortunatly, to write truely portable code one must test this value and normalize data accordingly.

The issues don't stop there though. I've seen many a more serious faux pas committed by the newbie. Another more serious flaw that I see happen on a regular basis is the use of user data within include statements without proper path checking. This is probably one of the more disasterous errors I see occuring because it typicly exposes sensitive data. There has been more than one occasion where i've shown a user their own passwd file in a browser to make my point.

Anyhow, to the newbies: we, the more experienced people of PHP are on our own quest to educate people, many times in a one-on-one basis on Freenode. If you're not sure about a particular issue, grab an IRC client and ASK US (irc://irc.freenode.net). We're there to help!

I know this concept from Perl DBI, but in PHP I haven't seen anyone (phpBB, ...) using bind_param. Why is this? Performance? Keeping the code short and simple?

The reason is that the function you reference is only available in ext/mysqli, and this requires MySQL 4.1 or greater. There was previously no way to bind parameters like this using PHP and MySQL.

Also, phpBB is not a good example to use with regard to secure programming practices. It is one of the applications that give people this silly notion that the language is to blame for poor programming.

AFAIK SQL injection can be prevented by binding the parameters to the SQL statement and not putting them within SQL.
An example:
It's easy to inject some malicious SQL when using the following PHP code:
mysql_query("INSERT INTO FOO('Bar') VALUES('$some_post_param');");
But if you prepare the SQL statement with parameters and bind the variable $some_post_param to the statement, it will be secure.
see mysql manual for mysqli_stmt_bind_param() aka bind_param
$stmt = $mysqli->prepare("INSERT INTO CountryLanguage VALUES (?, ?, ?, ?)"); $stmt->bind_param('sssd', $code, $language, $official, $percent);

I know this concept from Perl DBI, but in PHP I haven't seen anyone (phpBB, ...) using bind_param. Why is this? Performance? Keeping the code short and simple?

As for general webserver security: use PHP and perl as cgi, use suEXEC, run the webserver as nobody/www, put the users into chroot jails, but by all means, don't use PHP safe_mode On.

Once our novice gets more knowledgeable, he can convince his admin to remove gpc_magic_quotes setting from his VirtualHost, and use addslashes , instead, which allows finer grained operation.

That way, Peter O'Neill can register with his true name in his Php app.

The worst practice I ever saw was making the global variables local scope using the extract() function, in... every... single... file... especially the security login files - its almost like register_globals and v4.1 never happened.

Then again this is the same person who insisted in using the $array[key] array syntax which was never the correct way of doing to start with.

And this was the supergenius hired to replace me. Fun city. Glad I don't work there anymore.

</mode>

Damien

With php, there's a seperate function to open a connection to the database, per vendor.

Not if you use PEAR.

You are absolutely correct, however PEAR and PECL are definatly trying to fix this. Granted, they are nowhere near the size of CPAN, but Rome wasn't built in a day ;)

You are absolutely correct, however PEAR and PECL are definatly trying to fix this. Granted, they are nowhere near the size of CPAN, but Rome wasn't built in a day ;)

You want to substantiate your statement?

Is this the bug you are refering to?

If so, it's two years old and already fixed, unless there's a different upload bug...

You're confusing Perl with CPAN. Perl by itself doesn't allow you to connect to a database the way you described, you use CPAN's DBI to do it. Which is a database abstraction layer, same as PEAR's DB

PHP is not object oriented, therefore making it teh ghey.

Yes it is.

Links? References? Explanations?

Array do's and don'ts

I run PHP5 on one of my developer boxes(I should install it on the other one too, but I'm lazy), and as far as I know it's completely back-compatible(except from some new reserved keywords, but that's easy to fix). All the new features are really nice, and I have to say that I noticed a tiny gain in speed too.

There's no reason not to switch to PHP5, everyone please do it now! Writing back-compatible code is no fun, I want to use all the new and exciting OOP features.

Here's a page describing all the new features in PHP5 and the ZEND engine version 2!

SQLite is poised for a big boost. It's going to come bundled with the next version of PHP, PHP 5. That M in LAMP may be in trouble...

Rasmus Lerdorf (the inventor of PHP) has his slides online as well.

Isn't PERL dead??

I think you don't really need public/private/protected in a scripting language. More interesting for me are other improvements like that assignments like

$a = new foo();
$b =$a;

are made by reference. With PHP4 even the first line would create a copy of the object. Also interesting arenew extensions like MySLi, the new soap extension or the rewrite of the XML-Extensin based on libxml2 (including the realy nice SimpleXML-Extension) ....

A collection of PHP5 information can be found p.e. on this German site (most links lead to English pages, and I'm one of the ones running this site - so it's the best (German) PHP site *g*)

I think you don't really need public/private/protected in a scripting language. More interesting for me are other improvements like that assignments like

$a = new foo();
$b =$a;

are made by reference. With PHP4 even the first line would create a copy of the object. Also interesting arenew extensions like MySLi, the new soap extension or the rewrite of the XML-Extensin based on libxml2 (including the realy nice SimpleXML-Extension) ....

A collection of PHP5 information can be found p.e. on this German site (most links lead to English pages, and I'm one of the ones running this site - so it's the best (German) PHP site *g*)

I think you don't really need public/private/protected in a scripting language. More interesting for me are other improvements like that assignments like

$a = new foo();
$b =$a;

are made by reference. With PHP4 even the first line would create a copy of the object. Also interesting arenew extensions like MySLi, the new soap extension or the rewrite of the XML-Extensin based on libxml2 (including the realy nice SimpleXML-Extension) ....

A collection of PHP5 information can be found p.e. on this German site (most links lead to English pages, and I'm one of the ones running this site - so it's the best (German) PHP site *g*)

Compiling PHP on a 64bit platform worked since some times. As you can see at bug #27717 make test, after compiling failed at some tests, which work now. I know some 64bit isntallations even though I haven't such a machine myself....

It is nice with another bugfix release, but what I'm really looking forward to is the release of PHP 5 with Zend Engine 2.0. Then the object model will finally be sane (private/protected member variables for example).

PHP is actually even worse, because, although there are template engines for PHP, they lead to spaghetti objects

Smarty, the most popular PHP template engine, is actually very similar to Velocity. Velocity has a more pleasant syntax, while Smarty has more features (esp. caching). One is certainly a knock-off of the other. I don't know which was first, though.

smarty + turck mmcache = fast templating

For instance, I wanted to have "month" and "year" appear at the top of smarty's date select boxes, but you can't do that.

When you want to do something complex, you have to fall back to {php} blocks. For instance I needed to chunk an array into an array of 5-element arrays, for an online photo gallery type of application.

For instance, I wanted to have "month" and "year" appear at the top of smarty's date select boxes, but you can't do that.

When you want to do something complex, you have to fall back to {php} blocks. For instance I needed to chunk an array into an array of 5-element arrays, for an online photo gallery type of application.

For instance, I wanted to have "month" and "year" appear at the top of smarty's date select boxes, but you can't do that.

When you want to do something complex, you have to fall back to {php} blocks. For instance I needed to chunk an array into an array of 5-element arrays, for an online photo gallery type of application.

Your arguments are great but they apply for almost every lanugage I know of.

As for frameworks look at apache. Have you seen how many frameworks it has for java? What about Swing, AWT, SWT etc? Just because they're are lots of frame works doesn't mean it bad.

I agree with your class as a static function library but that's not PHP's fault. C++, Java and Perl have the same problem. When people learn C or VB first and then go to an OO langauge they generally get it wrong.

As for bad projects I sure if you did an "Ask Slashdot" they'd be able to tell you about bad projects C, C++, Lisp, PHP, Java, J2EE, .NET, etc.

As for a standard was of seperating logic from content lots of people say that JSP isn't enough that's why you have stuff like Velocity and all the other framework template engines. If you want a template engine for php the default one is Smarty.

When it come down to it the problem you have with PHP is that it has a lot of newbie programers that use it. Which is good and bad. Try making a simple form in JSP then do the same thing in PHP. PHP is ALOT easier. That doesn't mean it's better but it does mean people with a lower skill can do it. I'm using templates for our internal site and when other people edit it half the time the escape and got back to raw PHP and it's a mess so I fix it up and it's all clean again but they just don't get it untill after I show them then it make sense and they can do it but the next time they can't figure it out so it happens again etc.

Does it mean you get lots of bad half baked libraries YES does it mean you get good libraries and frameworks YES (because more poeple start, so more people get good at it).

If you want to look at good php projects check out:
* Smarty
* Mambo
* Gallery
* phpBB
* JpGraph
* phpMyAdmin

That being said at what level do you move someone from a "HTML + PHP Hack" to a "Web Developer"?

What makes a lanuage "enterprise-ready"? Does an "enterprise" company just have to use it (IE Yahoo and PHP). Or does it have to have faetures?

Where I work we still use PROC and PIC which is a 40 year old language that doesn't have:
* Variable Names - Only numbers!
* Functions - Only GOTO and GO SUB (again numbers no names)
* All variables are global!
* No loops!
* No else - You have to use IF and GOTO!

Yet this is still being used in thousands of companies all over the world! Sure it's legacy but it's enterprise ready and still being used!

So could it be used on a massive site handling 1,000 of concurrent users? Yes, IF IT WAS DESIGNED IN THE RIGHT WAY. It wouldn't be the same design as you'd use for .NET or the same as you'd use for J2EE but it would work. It might not be the best but that depends on the problem. (Same as Clusters vs Grid)

I've ranted engough ... have fun pulling my comments to peices.

Your arguments are great but they apply for almost every lanugage I know of.

As for frameworks look at apache. Have you seen how many frameworks it has for java? What about Swing, AWT, SWT etc? Just because they're are lots of frame works doesn't mean it bad.

I agree with your class as a static function library but that's not PHP's fault. C++, Java and Perl have the same problem. When people learn C or VB first and then go to an OO langauge they generally get it wrong.

As for bad projects I sure if you did an "Ask Slashdot" they'd be able to tell you about bad projects C, C++, Lisp, PHP, Java, J2EE, .NET, etc.

As for a standard was of seperating logic from content lots of people say that JSP isn't enough that's why you have stuff like Velocity and all the other framework template engines. If you want a template engine for php the default one is Smarty.

When it come down to it the problem you have with PHP is that it has a lot of newbie programers that use it. Which is good and bad. Try making a simple form in JSP then do the same thing in PHP. PHP is ALOT easier. That doesn't mean it's better but it does mean people with a lower skill can do it. I'm using templates for our internal site and when other people edit it half the time the escape and got back to raw PHP and it's a mess so I fix it up and it's all clean again but they just don't get it untill after I show them then it make sense and they can do it but the next time they can't figure it out so it happens again etc.

Does it mean you get lots of bad half baked libraries YES does it mean you get good libraries and frameworks YES (because more poeple start, so more people get good at it).

If you want to look at good php projects check out:
* Smarty
* Mambo
* Gallery
* phpBB
* JpGraph
* phpMyAdmin

That being said at what level do you move someone from a "HTML + PHP Hack" to a "Web Developer"?

What makes a lanuage "enterprise-ready"? Does an "enterprise" company just have to use it (IE Yahoo and PHP). Or does it have to have faetures?

Where I work we still use PROC and PIC which is a 40 year old language that doesn't have:
* Variable Names - Only numbers!
* Functions - Only GOTO and GO SUB (again numbers no names)
* All variables are global!
* No loops!
* No else - You have to use IF and GOTO!

Yet this is still being used in thousands of companies all over the world! Sure it's legacy but it's enterprise ready and still being used!

So could it be used on a massive site handling 1,000 of concurrent users? Yes, IF IT WAS DESIGNED IN THE RIGHT WAY. It wouldn't be the same design as you'd use for .NET or the same as you'd use for J2EE but it would work. It might not be the best but that depends on the problem. (Same as Clusters vs Grid)

I've ranted engough ... have fun pulling my comments to peices.

Personally, I'd LOVE to be able to write Perl / GTK2 apps that run under Windows, and it looks like I might be able to soon

Dunno about Perl, but with PHP-GTK, I've been able to do this for over a year with PHP. Combined with the Ion Cube compiler, I've been writing cross-platform Windows/Linux/OSX programs for quite a while.

type http://www.slashdot.org. into your address bar - WITH the trailing period

the "." is a special-character and delimits parts of the address - so if they were to perform an $sections = explode($url, '.') {PHP function reference} with $url="www.slashdot.org" or $url="www.slashdot.org." they would get $sections = array ("www", "slashdot", "org") or $sections = array("www", "slashdot", "org", "") - and they discard empty strings for tidiness

so you'd have to suddently patch every DNS server in existance at the same time for "." to be it's own TLD

Apache2 has a number of different modes it can work in. These modes are called MPM's. The default MPM is called Worker which is a multithreaded model. PHP, mod_perl, mod_python, and any other similar technology which links directly into the httpd processes will need to be perfectly threadsafe and reentrant to work effectively with a threaded Apache2 mpm. This is doable for the core of PHP, but there are literally hundreds of 3rd party libraries that can be linked into PHP and nobody whether or not these libraries are threadsafe. And figuring out if a specific library is threadsafe or not is non-trivial and it can very from one platform to another. And just to make it even harder, this stuff will appear to work fine until you put it under load or hit very specific race conditions which makes it nearly impossible to debug.

So, since we can't tell you for sure that a threaded Apache2 mpm + PHP will work we do not suggest you use it for a production server. And since we can't know for sure, none of the main PHP developers use this combination for our own servers which compounds the problem because it is not receiving anywhere near the amount of realworld testing required to work out all the little issues above and beyond this threading unknown.

There is an Apache2 mpm, called "prefork", which isn't threaded and basically makes Apache2 look like Apache1. But hey, we have a very good server already that looks like Apache1.

In the end I don't see Apache2+PHP ever becoming a production platform with the current architecture. The only way I see it ever working is to pull PHP out of Apache and use a fastcgi approach. Or, with time, perhaps we will learn how to make sure a library is perfectly threadsafe and safe to use in a multithreaded Apache2.

For now, I really see no reason not to simply use Apache1 if you want a robust, fast and stable web server.

One of the posters found this more recent comment from Rasmus as well:

We are not talking about just Apache2 here. We are talking about Apache2+an MPM+PHP+3rd Party Libs. The folks at apache.org are only concerned with Apache2 itself, and for serving up static files it is better than Apache1 in many respects. However we have to worry about a lot more stuff here. In fact, we couldn't care less about serving up static files. The main issues as I see them are:

1. Thread safety issues. - It is very difficult to track down threading problems and we don't have decent tools to help us. The thread safety of many 3rd party libraries are unknown quantities and can depend on the OS, libc and even compile flags. - Many distributions seem to ship with the Worker MPM as the default and that is the MPM that gets the most attention. This is a hybrid multi-process, multi-threaded MPM.

2. You can eliminate the threading problem by running the prefork MPM which effectively makes Apache2 behave just like Apache1 in the way it forks processes and serves one request at a time per process. Issues here: - Apache2 itself is rather fringe still. It has approximately a 5% marketshare vs. 65% for Apache1 at the time of this and out of that I would guess the majority are running the Worker MPM. So we are talking about a fringe MPM in a fringe server. This means it has not had anywhere near the attention from people running large production web server farms that it needs for me to comfortably say that this is a solid piece of code with all the kinks worked out. - The benefits of moving to Apache2+prefork are questionable. The new filter API would be one of the benefits, but it sti

The PHP manual link posted is a direct link to one of the Canada mirror servers. The PHP site is mirrored around the world and it automatically selects your nearest mirror server.

Use http://www.php.net/manual/en/install.apache2.php instead so that it can select the nearest mirror server and save us slashdotting this one Canadian server :D

Yeah it's a shame there is no *_pconnect calls in PHP.

See : Creating Extensions

I know this is only slightly related...but while looking at improvements with PHP, check out this powerful template engine written in PHP:
Smarty.php.net now at version 2.6.2 with improved cache ability.

Many of those one-off scripts end up with lengthy lives all their own. PHP has a long way to go in many areas (namespaces, library vs. core functions) but many of the old arguments are just out of date. Also, Perl has a bad rep for ugly unreadable code because a significant number of Perl programmers write ugly unreadable code.

Does PHP have a good, high-quality templating system bundled yet?

Smarty

We are not talking about just Apache2 here. We are talking about
Apache2+an MPM+PHP+3rd Party Libs. The folks at apache.org are only
concerned with Apache2 itself, and for serving up static files it is
better than Apache1 in many respects. However we have to worry about a
lot more stuff here. In fact, we couldn't care less about serving up
static files. The main issues as I see them are:
<p>
1. Thread safety issues.
- It is very difficult to track down threading problems and we don't
have decent tools to help us.</blockquote>
- The thread safety of many 3rd party libraries are unknown
quantities and can depend on the OS, libc and even compile flags.
- Many distributions seem to ship with the Worker MPM as the default
and that is the MPM that gets the most attention. This is a hybrid
multi-process, multi-threaded MPM.

2. You can eliminate the threading problem by running the prefork MPM
which effectively makes Apache2 behave just like Apache1 in the way it
forks processes and serves one request at a time per process. Issues
here:
- Apache2 itself is rather fringe still. It has approximately a 5%
marketshare vs. 65% for Apache1 at the time of this and out of that I
would guess the majority are running the Worker MPM. So we are talking
about a fringe MPM in a fringe server. This means it has not had
anywhere near the attention from people running large production web
server farms that it needs for me to comfortably say that this is a
solid piece of code with all the kinks worked out.
- The benefits of moving to Apache2+prefork are questionable. The
new filter API would be one of the benefits, but it still has some
issues and by default we run PHP as a handler, not a filter currently.
You can optionally run it as a filter but people have had problems with
that.

Until such a time when enough clueful PHP people think there are enough
realworld useful features in Apache2-prefork or even Apache2-threaded to
actually sit down and bang away at PHP and the majority of the PHP
extensions under Apache2. Or if enough regular users report back that
they tried it and had absolutely no problems then we will change our
reccomendation, but for the time being I don't think that we in good
faith can tell users that Apache2+PHP is something they should be
putting into production.

In the changelog for PHP, it is suggested that all exceptions _must_ inherit from a base 'Exception' class

Hmmmm....


"Even though the above example shows that it is possible to define exception classes that don't inherit from Exception it is best to do so. This is because the internal Exception class can gather a lot of information otherwise not available."

http://www.php.net/zend-engine-2.php


- Scott

That's my impression as well. A somewhat simplistic description of PHP 4's syntax is that it's similar to Perl, but is resembles 'C-like' syntax more than Perl does. A lack of things like implicit variables in PHP seems to make it a little easier to come back to a project months later or look at someone else's code and follow the program logic a little more easily than Perl is. (PHP 5 is adds syntax features that resemble Java more, as well).

PHP has a fair amount of strength in the text-handling area, similar to Perl, but PHP is a bit more 'focussed' on talking to network servers (database servers, webservers, network sockets, ftp servers...).

On the other hand, PEAR and PECL don't have nearly the mind-boggling breadth of add-on modules that Perl's CPAN does...

(As usual, I'm compelled to note that PHP is no longer 'just for web pages' any more than Perl is 'just for generating reports'. I've found it handy for a lot of small system administration tasks that Perl is also good for. You can even use Ncurses or GTK - or, conceivably, Java GUI classes to build standalone apps with it, if you feel the urge...)

That's my impression as well. A somewhat simplistic description of PHP 4's syntax is that it's similar to Perl, but is resembles 'C-like' syntax more than Perl does. A lack of things like implicit variables in PHP seems to make it a little easier to come back to a project months later or look at someone else's code and follow the program logic a little more easily than Perl is. (PHP 5 is adds syntax features that resemble Java more, as well).

PHP has a fair amount of strength in the text-handling area, similar to Perl, but PHP is a bit more 'focussed' on talking to network servers (database servers, webservers, network sockets, ftp servers...).

On the other hand, PEAR and PECL don't have nearly the mind-boggling breadth of add-on modules that Perl's CPAN does...

(As usual, I'm compelled to note that PHP is no longer 'just for web pages' any more than Perl is 'just for generating reports'. I've found it handy for a lot of small system administration tasks that Perl is also good for. You can even use Ncurses or GTK - or, conceivably, Java GUI classes to build standalone apps with it, if you feel the urge...)

That's my impression as well. A somewhat simplistic description of PHP 4's syntax is that it's similar to Perl, but is resembles 'C-like' syntax more than Perl does. A lack of things like implicit variables in PHP seems to make it a little easier to come back to a project months later or look at someone else's code and follow the program logic a little more easily than Perl is. (PHP 5 is adds syntax features that resemble Java more, as well).

PHP has a fair amount of strength in the text-handling area, similar to Perl, but PHP is a bit more 'focussed' on talking to network servers (database servers, webservers, network sockets, ftp servers...).

On the other hand, PEAR and PECL don't have nearly the mind-boggling breadth of add-on modules that Perl's CPAN does...

(As usual, I'm compelled to note that PHP is no longer 'just for web pages' any more than Perl is 'just for generating reports'. I've found it handy for a lot of small system administration tasks that Perl is also good for. You can even use Ncurses or GTK - or, conceivably, Java GUI classes to build standalone apps with it, if you feel the urge...)