Re: Fwd: What's up with Quercus?
| From: | Gwynne Raskind | Date: | Sun, 29 May 2011 05:05:47 +0000 |
| Subject: | Re: Fwd: What's up with Quercus? | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-52533@lists.php.net to get a copy of this message | ||
On May 28, 2011, at 10:55 PM, Martin Scotta wrote:
> I really dont like to move away from PHP, but compared to others... it's
> just a template language with steroids.
>
> and please dont get me wrong, I love PHP, it's is still my favourite but...
This has been exactly my experience when trying to use PHP in any meaningful way. For example,
trying to use PHP as a network server:
- I immediately had to write an extension to give me access to several missing APIs (clock_gettime()
and a number of ncurses functions not implemented in the ncurses extension).
- In order to use stream_select() with both network sockets and STDIN, I had to merge
socket_select() with stream_select() in my extension, as in 5.3 stream_select() doesn't
preserve socket array keys (this was fixed in 5.4)
- To make use of pack() and unpack() for packet management, I had to reimplement them so as not to
throw notices willy-nilly when I got bad packets. (Adding format specifiers that could handle useful
data types not in the original API was just a bonus.)
- In general, I have to tiptoe all over everything to avoid getting useless notices/warnings for
expected error conditions (such as SIGPIPE on dying sockets, passing zero sockets to
stream_select(), trying to fopen() a nonexistant file, and so forth).
- No threading support.
- No preprocessor. define() makes up for only some of it, closures make up for some more, but still
not enough. There are no mature opensource preprocessor implementations for PHP that I can find
(just betas of various sorts), and both GCC's and Clang's CPPs break on here/nowdocs. More
generic preprocessors (like m4) tend to have learning curves or problems of their own.
- (Almost) everything here: http://www.phpsadness.com/
- No Unicode.
If there is any direction for PHP 6, I'd like to see that direction be dealing with problems
like these. PHP has been used more and more as a general-purpose language, when it wasn't
designed to be. Addressing that would solve a lot of core problems. And yes, it does mean an engine
rewrite.
-- Gwynne