Graceful recovery
at 2007-08-12 15:10:22
Right now some situations (parse errors, undefined function call, no more memory) in PHP result in fatal error - which means the engine can not continue with the request beyond this point. From the user point of view, this often results in a blank page. I wonder if it would be possible to have standard recovery mechanism that would allow the PHP engine on fatal error to enter some kind of “recovery mode” when it would output some very basic page saying “ok, I have some problems here, but don’t panic and just tell my programmer to fix the code”. It won’t give much info probably but it would allow production sites display nice message to the users instead of the boring snowfield panorama it displays now (that is if the administrator was smart enough to set display_errors to off).
Maybe it should allow only fixed HTML, or maybe some kind of “request recovery” mode which would create some “recovery mo
Kill resources at 2007-08-12 15:10:22I wonder why we still have resource type in PHP?
Since 5.x, objects are perfectly capable on encapsulating any void * transparently (there’s at least 2 Java bridges doing that, for example) and of course using objects doesn’t force you to use OO syntax - i.e. you can do fread($foo) with $foo being either resource or object equally well. We can see ext/unicode/collator.c in PHP 6 as one example of dual interface also (I’m sure there are more, I just had to pick one). So objects as I see it can do anything resources can do. And much more - you could extend it (had we had file as object and not resource, streams probably would be much easier to implement), serialize it (provided correct methods of course), etc., etc.
Also, with some effort I think it would be possible to modify all resource-using code to
We are doomed! at 2007-08-12 15:10:22Generally I enjoy reading all kinds of “PHP sucks” and “PHP is doomed” articles, of which there’s no shortage. First, many times the authors have very interesting ideas on places where PHP does suck and can use improvement - and the more good ideas the merrier. Second, once you read a dozen of them you can’t help noticing how people say PHP sucks and is doomed for entirely contradictory reasons which makes it fun. And last but not least - if people write about flaws of PHP it means they care. Nobody writes about why PL/1 sucks and how Clipper is doomed 
Recently on PHP blogs I saw a reference to one blog entry - named “PHP is Doomed!” of course - that proclaims PHP is doomed for one single reason - it doesn’
Namespaces - can we keep it simple? at 2007-08-12 15:10:21Dmitry Stogov has published the patch on PHP-internals implementing the simple namespace model for PHP that I co-authored. I urge everybody to please take a look and discuss it - best on the internals list since the audience is bigger, but comments here are welcome too.
The main idea of the proposal is to attack one target and this target only - the Super_Long_Really_Annoying_Enormous_Class_Names that lately became the bane of big project developer. All other things are considered secondary to this goal - no attempt to make some different include model, packaging model, etc. This approach, in my opinion, allows to greatly simplify the concept and the mechanics involved. It allows to reduce most of the work to simple text transformation, without any need to create complex hierarchies with obscure rules.
Of course, there are some edge cases still, b
Linux World at 2007-08-12 15:10:21
I will be speaking at Linux World on August 7, 11:30-12:30 about PHP and Web 2.0 development. So everybody who’s going to be there is welcome to come and listen 
|