Simon Willison’s Weblog

Interesting presentation. Looking forward to the talk Christian is doing for the PHP UG Switzerland next year.

The lack of a smart namespace system (like Pythons modules) really gets in the way when you start trying to write reusable code or large applications.

Personally have never found this a significant problem.

Where DOM is concerned, if you notice in the presentation examples there's things like;

$dom = new DomDocument;
$dom->load("book.xml");
$dom->getElementsByTagName("book");

The load() and getElementsByTagName() methods are not in the default namespace but only available via the instance of DomDocument. The DOM extension is unusual in PHP as it's a collection of inbuilt classes not functions.

In general PHP's built in functions are fairly well "namespaced" e.g. mysql_query, mysql_connect etc. Also PHP throws a fatal error if you attempt to redefine any of these yourself, so it's not a story of wierd bugs. And if you use classes, it's not a problem.

As to classes themselves, PEAR shows an effective strategy for namespaces e.g. XML_Parser, XML_Serializer etc. That said normally you wouldn't include many classes in the first place (assuming no script cache) as you only want PHP to parse those needed in the current request.

Sure Python is a better designed language (and nice to have "script caching" bundled for free - therein may lie the answer to why namespaces are not in PHP5...) but PHP has massive adoption and, once you know it's quirks, is most capable of scaling to demand.

Harry Fuecks - 21st December 2003 00:57 - #

It isn't a huge problem in practise, but it's a niggling one - especially when you want to write code for other people to use where it could be being combined with any number of other scripts. I tend to end up writing everything in PHP as a class just to try and reduce namespace polution, even when some of the code would make more sense as a standalone functions. One of the most liberating things about Python's modules is that suddenly writing standalone functions is OK again - since they live in the module they are defined in (with other related functions) there's no danger of collisions.

Simon Willison - 21st December 2003 01:05 - #

Know the feeling - that niggling is occasionally deeply depressing ;) Likewise tend to having stuff like Utils::someFunc() to avoid functions.

The web would be a better place if Python was in PHP's shoes (to the point where it would likely make Microsoft and Sun very nervous no doubt). Adam Trachtenberg makes some interesting remarks as to "Why PHP?" here [PDF] (in the "Growth of Apache" section). The points on mod_perl could, to some extent, apply to mod_python as well though - a solid Python pre-processor (whatever those that complain about code and HTML mixing may say) would probably do alot to boost it. Being so easy to deploy and get started, PHP is very attractive to beginners.

Harry Fuecks - 21st December 2003 01:30 - #

I can't say I've ever had a problem with clashing function names - even in large projects. I tend to prefix my function names with something along the lines 'form_' or 'db_' realting to the libarary they are declared in. If I'm re-engineering a built in function I prefix with 'my_' (e.g. my_date()).

PHP5 OOP looks really cool. I got out of the OOP methodology when I started coding with PHP (I still code in VB6 which is only vaguely OOP) but after a bit of a fiddle with the PHP5 beta, I'm looking forward to getting back into it again.

I don't think I'll ever go 'full on OOP' in PHP - functions can be more intuitive and less verbose in places.

Richard Allsebrook - 21st December 2003 07:53 - #

This is all good. The most off-pissing aspect of PHP4 for me is the lousy XML support. I learned most of my XML/XSL with the standard Microsoft implementations which, whilst slow at runtime, have pretty good programming interfaces. PHP4's event driven XML handling functions were of little use, and the DOM stuff is still experimental. It's good to see some proper XML support in the pipeline. This stuff is becoming more and more critical, as it has got to the point where clients (especially in the public sector) are demanding XML implementations in their web applications, and it be honest, you can't argue with such a reasonable demand.

Drew McLellan - 22nd December 2003 21:27 - #

I agree that i don't like the lack of namespaces in PHP. Using the MySQL example (and there are many more statically linked extensions that could be easily used here), the global namespace has the functions

  mysql_connect()
  mysql_select_db()
  mysql_query()
  mysql_fetch_object()
  mysql_free_result()
  mysql_close()
  /* ... */

What I (and many other developers i'm sure) would like to see is something similar to the following:

  import("mysql"); /* arbitrary function to "import" the extension */
  $link = mysql::connect("localhost", "username", "password");
  mysql::select_db("database");
  $result = mysql::query("SELECT fieldname FROM tablename LIMIT 1");
  /* ... */
  mysql::close($link);

If the PHP group were to implement such an extension scheme, backwards compatibility would be non-existant. Some day, though..

Roman - 22nd December 2003 23:31 - #

That example is very poorly formed. If you have to qualify every function call with it's method name, you might as well munge your names (which is the defacto standard in PHP). Your example also takes more characters on every line than the 'pure PHP' version. Packaging systems unless you can actually import exension function names into your scope so that you don't have to qualify them.

George Schlossnagle - 23rd December 2003 05:53 - #

One more interesting note on the new XML support which doesnt seem to be in the presentation is calling PHP from XSLT - currently being discussed in the PHP-XML mailing list.

My guess on the namespaces front is as long as "script caching" is not part of the default functionality provided with PHP, an effective import command will be too expensive in terms of performance, the import happening at runtime while it's really a "compiler directive".

That said, when it comes to your own scripts, if you're particularily obsessed it would be possible to implement your own import function in a manner that might perform as well as normal code. Using PHP_Parser you could re-write the source file, perhaps changing the name of class, then cache the "compiled" result somewhere, so future calls can use the "compiled" version.

For PEAR, for example, that might mean where today you have to do;

require_once 'XML/Parser.php';
$parser = new XML_Parser();

Instead you might have something like;

import('XML.Parser');
$parser = new Parser();

...all for the small gain of being able to instantiate the parser with just new Parser() rather than new XML_Parser()

Harry Fuecks - 23rd December 2003 13:13 - #

I have to say I use PEAR on a usual basis.

Evan Wagner - 5th January 2004 20:28 - #

Harry "Call any PHP5 function in XSL" was not in the PHP Conference slides, because this functionality didn't exist back then ;) There's now a slide in my latest presentation about that. Besides from that, there's not much new in this talk compared to the one mentioned by Simon chregu

chregu - 16th January 2004 15:22 - #

all your talks about the "using XML; Parse(...)" is the same concept the .Net framework uses; namespaces! I still swear to ASP.NET because it's compiled - but that's another story.

anars - 25th August 2005 01:13 - #