Re: PHP review
| From: | Chuck Adams | Date: | Fri, 02 Jun 2000 05:55:12 +0000 |
| Subject: | Re: PHP review | ||
| References: | 1 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-887@lists.php.net to get a copy of this message | ||
Teodor Cimpoesu writes:
> What do you guys think of the 'cons' listed at the bottom?
The review seems so cursory, and the pros and cons so few, I'll list
them all and add a few of my own
PROS:
* Powerful, open and scalable
* A large (and ever-growing) number of extensions
* Support for all Web standards
* Easy to learn
CONS:
* Rudimentary session management
* Database access is not unified
* No database connection pooling
The pros, I agree with, though supporting *ALL* web standards is
saying a bit too much. DAV is after all, not supported, since the
module just plain doesnt work (see the PHP dev list, they're talking
about putting in a #error directive in the source to disable it by
default)
As for the cons.
> * Rudimentary session management
Seems more to me to be *undocumented* session management. The quality
of the manual is uneven, and session management gets very short
shrift. Short enough that I reckon it just wasn't important enough to
mention, so I don't even use it. If it's a major feature, I sure
can't tell.
> * Database access is not unified
Not only is database access not unified like Perl's DBI/DBD system,
there's not a damned thing in PHP that feels "unified". If you open a
pipe with popen, you have to use a different method to close it. God
forbid you should ever create your own stream class. With everything
thrown into a single global namespace of functions, there is no hope
whatsoever for standard interfaces for similar functions (serialize
and wddx should have been subclasses of the same object, for example).
PHP is a complete ad hoc hodgepodge and shows every sign of getting
worse in this respect. Modules need to live on objects, objects that
define a standard interface, not littering a global namespace of very
non-OO functions. Think I'm being fairly clear on this?
> * No database connection pooling
I thought most of the interfaces supported a "persistent open"
function, that seems to implement a pool for me. Even the
non-persistent connections are memoized and pool within the same
request. Not sure where this con came from, it doesn't appear to be
true at all.
Anyhow, I have a litany of gripes about PHP, its myopic focus as a
"web only" language (imagine what would have happened to a
"gopher-only" language?) and so forth. I hope to air some of them
eventually, but there's my take on that article.
chuck