Crazy idea for today - operator to check conformance to specific interface without actually implementing it. Why one would want that?
Well, if you are into duck typing style of programming, it may be interesting for you to have an object that implements certain set of functions, but not necessary declares it at class definition. Languages like Smalltalk do it all day along, so why PHP couldn’t? The idea is it looks like this:

interface Cow {
  function moo();
  function eatGrass();
}
/* somewhere else */
class MooingGrassEater {
  function moo() {/*stuff */}
  function eatGrass() {/*stuff */}
  /*stuff */
}
/* somewhere else */
function CowConsumer($classname) {
$foo = new $classname();
if($foo implements Cow) {
  echo "Behold the cow:";
  $foo->eatGrass();
  $foo->moo();
} else {
  echo "$classname is not a cow!";
}

implements here is our duck operator. Note that unlike instanceof, no formal relationship is required, but only practical implementation. So another name would be “common law marriage operator”

Of course, this one would be anathema to “strict OO” camp, so if you subscribe to that, just ignore this post

Two challenges to this idea are:

1. __call() - we have no way to know what __call does. So either we ignore it or say “ok, __call does everything”. I’d go for the latter.
2. Performance. To check duck implementation one basically would have to match method lists, which amounts to number of is_callable calls equal to the number of methods in interface being checked.

Actually, PHP uses this style sometimes - see, for example, user defined streams. But there’s no nice way to work with it from the consumer side.

So, another “PHP sucks” post, this time from Jeff Atwood. He actually ends up even kind of praising PHP, surprised by its success. I have a couple of thoughts on that topic too.

First, people really need to stop reading something on PHP written somewhere in 2005 (probably about experiences that happened in 2001) and apply it to PHP as it is now, without even checking around for current trends. It’s as if people would dig up books from middle ages saying that there are only seven metals in existence or debating about phlogiston, and would use it speaking about the modern chemistry. Come on!

Then the next thing apparently wrong with PHP is too many functions. Right. Since when? Since when having a lot of functions is a problem? Does it hurt anybody? Does it make writing PHP code harder? Does it make programmer less successful in achieving his goals?
About keywords I could kind of understand - OK, a lot to remember (though I didn’t see anybody really having trouble to remember such complicated keywords as “while”, “if”, “class” or “public”) and it takes out some good English words that could be used as function/method names to confuse the enemy (who wouldn’t want to have function named endforeach() or static(), not to mention function()? too bad those are not available!). But complaining there’s too many actual functions that allow you to do real useful stuff? That is the thing that is bothering people? That is what scares people away from using the language “for years”?

The next beef with PHP is that people write sucky code on it. No, really, they do? Must be something really wrong with this language. It’s not like people write mind-bogglingly sucky code on every other “good” language on the planet. But I get it. The intent was - PHP makes easy to write sucky code. Yes, this is true. As true as “Porsche 997 makes it easy to drive at 100mph into a brick wall”.  PHP makes it easy to write various kinds of code - and if 90% of code written is sucky, then 90% of PHP code would be sucky. But my experience says quality of the production code almost never has much to do with the language, but only with the culture - organizational and personal, and with choosing right ways to do the job. The rest is just bad statistics in play. Like “I know 7-year-old writing websites, and his PHP code sucks”. I bet his Haskell code rules though

That’s not to say PHP couldn’t use improvement. It could. And it does, actually - and there’s enough room for improvement still, in many areas. But it probably would never satisfy purists. It’s practical. Maybe it doesn’t allow you to write whole programs in one line of uncomprehensible character soup or play with high-level math theory concepts, but it allows people to write web applications. So they do - so where’s the surprise when one morning somebody wakes up and discovers there’s a ton of web applications around and they are written in PHP?

P.S. I wish for every 50 “PHP sucks” blogs people would write one good RFC.

One of the things I am doing in course of my work is performance benchmarks for various stuff - PHP, Zend products, applications, etc. Performance in PHP space is currently like alchemy - there are a lot of rumors floating around about various properties of various stuff, but much less reliable data that can be verified and used. PHP has standard bench.php script, but it covers only a small part of what real-life applications do. I wish there were more established tests and methods for benchmarking PHP engine and applications. But benchmarking is a complicated subject, and variety of PHP platforms and applications makes it harder to create useful general-purpose benchmarks.

But more to the point. On Zend Framework lists there was a topic raised about performance impact of Zend_Loader component, which is used for - no surprise here! - loading classes, including autoloading, etc. Some folks thought that since Zend_Loader is executing some code before actual loading the required file, it must cost something. And it makes sense. However, how much does it cost?
Well, the best way to know the price of something is to ask - and in this case, to run the test. So that’s what I did - I made a list of 725 Framework classes (ZF now has more than 1000 but I composed the list some time ago and had also to drop some to avoid some tricky dependencies). And I wrote two scripts - one that would load these classes with require_once and one that would load them using Zend_Loader::loadClass. Both the data file and the scripts are available for download for those that would like to play with it. I tested them with and without Zend’s bytecode cache, to see how much one can save using bytecode caching technology.

So, the results were as follows:

Without bytecode cache:

          require_once Zend_Loader
php5.2        4.42      4.42
php5.3        4.96      4.97

With bytecode cache:

           require_once Zend_Loader
php5.2        63.04     56.62
php5.3        61.28     55.52

The numbers are requests per second, so more is better. Test run on Linux dual 2GHz AMD.

What we can conclude from these?

1. It is very important to understand that it is a narrow-point benchmark that tests only one function in one specific way. Please do not draw conclusions on behavior of whole applications based only on this benchmark.
2. You do want to use bytecode caching. You won’t get 15x performance on any real application, but it does speed up loading very significantly.
3. Without bytecode caching, it doesn’t matter if you use require_once or Loader - both are equally slow
4. With bytecode caching, Loader has some overhead - explanation for this is that with file accesses eliminated, require_once of course has little left, while Loader still does a couple of function calls. But on real-life apps it’d probably be very small, provided that it’s about 10% even on loading-only huge-class-list benchmark, and your application probably does something useful instead of loading 700+ framework classes :)) Meaning, fears of using the class loader vs. doing require_once are seriously overstated.
5. 5.3 is still a moving target, to don’t put too much stake in current benchmark results for 5.3, they probably will be different by the time 5.3 is in release cycle (hopefully, better :))

P.S. This post does not talk about other things like “what if I stuff all classes I use into single file”, etc. Maybe next time.

PHP has a setting named display_errors that allows one to specify if various error messages should be sent to the output or not. It is recommended to keep it off, especially for the public sites, since it may reveal too much information about the application, and looks awful when seen on a public site.

However, for a developer an error report shown in time and place may prove quite valuable and usually is easier to work with then logs, etc. Of course that would mean - keep errors on in development, off in production. OK, then what we do if something weird happens in production and we want to see the errors, but we don’t want others to see them?

ASP has an interesting feature here - it allows you to display detailed error page only when accessed from local browser, but display something generic when accessed from “outside”. Maybe PHP could have some setting like display_errors=local which would enable display_errors for requests originating from developer machine but would disable it when outsider accesses it? Of course, this should be carefully done to prevent security problems, but I have a feeling it might be useful.

This can be done with an extension or even user-defined prepend script, but I think system-level mechanism might help people to use it correctly and avoid embarrassing themselves with publicly-displayed errors while keeping the stuff easy to spot for developers. Would that be useful?

I saw in Ben Ramsey’s blog the link to the eWeek’s “100 Most Influential People in IT” list and this:

60. Stefan Esser
Security researcher
Esser’s “Month of PHP Bugs” project thoroughly exposed the insecure nature of the widely deployed PHP language and forced a rethink of security in the open-source world.

I think Stefan Esser is doing great work by helping make PHP more secure, and so I join the congratulations for being in the list. I don’t really know what 60 means - is half as influential as #30 (Brendan Eich, Mozilla’s CTO) and 1/4 of that of the number 15, Linus Torvalds himself - or they just had to order it because otherwise it is hard to comprehend - but I guess any place in the 100 is great.

What drew my attention, however, is the wording of the description. Namely “thoroughly exposed the insecure nature of the widely deployed PHP language” and “forced a rethink of security in the open-source world“. MOPB was very useful in making PHP better, however I do not see how reporting a bunch of vulnerabilities (most of them fixed by the time of publication - for which thanks to Stefan Esser as the responsible reporter) is “thoroughly exposing the insecure nature of PHP”. Bugs and bug reports - including ones that may affect security in one way or another - are nothing but commonplace in both open-source and non-open-source software worlds. There’s nothing groundbreaking or “exposing” - there’s no secret that programs have bugs and nobody ever denied that in context of PHP or made any claim that I know of that was disproved by publishing these bugs.

I also fail to see how the fact that PHP had 43 bugs (MOPB reported 46 issues, 3 of them not in PHP) in various versions and various modules could force anybody to “rethink of security in the open-source world”, whatever that might mean. Just for the right perspective, main PHP source has now around 80 extensions, issue count on bugs.php.net now nearing 45000 (of course, many of them bogus, but still). To compare, Firefox’s Bugzilla counter approaching 430000 by now. I do not know how many of the bugs reported can be thought of as security bugs, especially provided that many bugs not thought of as security problems per se could lead to security problems given suitable context. Probably a bunch of them. But I do not see how that leads to any “rethinking”. Of course it leads to the plain old thinking - how to fix such bugs and try and prevent future ones like them - but that’s how it always worked and always will work, nothing special.

I’m writing this not to cast any shadow on the list or Stefan Esser’s work. I just think while the recognition of the security research efforts is great, the sensationalist manner that was chosen by eWeek to describe it is just wrong.

I’ve posted the first beta of PHP Internationalization extension, bringing support for some ICU functions to PHP. Documentation can be read in PHP manual, and the downloads are available on PECL site.

If everything goes well, we’d have that one in 5.3, and then probably add more functionality (suggestions welcome!).

The slides from my ZendCon 2007 Presentation (PDF) - they will be also on the main ZendCon site eventually but in the meantime they are here.

The example code can be downloaded from the Devzone.

I will be speaking at ZendCon 2007 on October 9th, about PHP and Rich Apps development. Welcome!

We now have an implementation of namespaces in PHP 6 HEAD, so here’s a short FAQ about how they work for those that are too laz^H^H^Hbusy to read the whole README.namespaces.

Q. Why PHP needs namespaces?
A. Because long names like PEAR_Form_Loader_Validate_Table_Element_Validator_Exception are really tiresome.

Q. What is the main goal of the namespace implementation?
A. To solve the problem above.

Q. What “namespace X::Y::Z” means?
A: 1. All class/function/method names are prefixed with X::Y::Z.
2. All class/function/method names are resolved first against X::Y::Z.

Q. What “import X::Y::Z as Foo” means?
A. Every time there’s Foo as a class/function name or prefix to the name, it really means X::Y::Z

Q. What “import X::Y::Z” means?
A. “import X::Y::Z as Z”, then see above.

Q. What “import Foo” means?
A. Nothing.

Q. What is the scope of namespace and import?
A. Current file.

Q. Can same namespace be used in multiple files?
A. Yes.

Q. Is there any relation between namespaces X::Y::Z and X::Y?
A. Only in programmer’s mind.

Q. How do I import all classes from namespace X::Y::Z into global space?
A. You don’t, since it brings back the global space pollution problem.
Instead, you import X::Y::Z and then prefix your classes with Z::.

Q. But doesn’t it mean I will still have long names?
A. Not longer then three elements: Namespace::Class::Element.

Q. Why it is not implemented like in <insert your favorite language here>?
A. Because PHP is not <insert your favorite language here>

Also we are considering to add one more feature to namespaces - ability to declare a namespaced constant - i.e. constant named Name::Space::NAME - with same resolution rules like classes - with const operator. Consequently it may be also possible to have const NAME = ‘value’ in global context, meaning the same as define(’NAME’, ‘value’).

Also note namespaces are still work in progress, so it may happen it would be changed a lot when it’s released.

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