PEAR and PHP 5

Hi folks, I've been very very busy for the last month, so I haven't been able to follow much of the pear traffic. But it is very re-assuring to see that the PEAR community maintains itself now and that people are stepping up to take care of things. Lukas and I had a chat the other day where we decided that he would take over the community stuff now, and I will focus on the infrastructure, hopefully leading to PEAR 2.0 by the time PHP 5 is released. Now to namespaces: I think it's important to keep clear mapping between the different types of entities in PEAR, such as packages, namespaces andclasses. Today we have a very simple system: Package_Name Package_Name_Class Package_Name_Class::method() Package_Name_function() Unfortunately, the coding standard is not followed 100% in all packages (I guess we all have our sins there :), but let's regard that as something that will be fixed. I agree that having "PEAR" as part of the namespace is good. It does add a zillion "PEAR:" prefixes around in code, but claiming the "top-level" namespace as our own is not a very nice thing to do, so we just have to live with that. Next, it should be possible to determine the relationship between packages and namespaces easily, and IMHO the only way to do that is to simply use the package name as-is in the namespace. So the examples above would be: Package_Name PEAR:Package_Name::Class PEAR:Package_Name::Class::method() PEAR:Package_Name::function() It may be prettier to replace underscores with colons in the package name, but I'm kinda reluctant to go all the way without having a plan for PHP 4 compatibility (see below): Package:Name PEAR:Package:Name::Class PEAR:Package:Name::Class::method() PEAR:Package:Name::function() IMHO, the most difficult issue we're facing here is how to migrate from PHP 4 to PHP 5 gracefully. I believe that forking everything will cause havoc. That would be basically splitting the community in two, where the "PHP 5 guys" would fork packages working in PHP 4 and add all kinds of ZE2 candy without caring about the PHP 4 users. It would suck if PHP 5 users could not use PHP 4 PEAR packages out of the box (it would most likely work, but any changes that we do in the standards could break it), because that _will_ lead to forking. And since I've convinced you all that forking is evil by now, you should all buy this idea: What we could do is to always bundle ext/tokenizer in PHP 5 and re-format symbols in PHP 4 PEAR code during install. The purpose of this is to provide forward compatibility, so PHP 5 users can use PEAR packages written for PHP 4, without having to worry about re-writing any code when the package finally "goes 5". Let's take XML_Parser as an example. When a PHP 5 user installs the PHP 4 XML_Parser package, the PEAR installer rewrites the code like this: class XML_Parser extends PEAR { to: namespace PEAR:XML:Parser { class Parser extends PEAR { And also: class XML_Parser_Error extends PEAR_Error { to: namespace PEAR:XML:Parser { class Error extends PEAR:Error { PEAR 1.1 already does checks that code confirms to the naming standard, taking it one step further should not be too hard. But this approach requires that the coding standard is followed strictly (which is exactly one of the reasons for the check in PEAR 1.1). Let me repeat the benefits of doing this: * no need to split PEAR in one PHP 4 world and one PHP 5 world * PHP 5 users will have access to most PEAR packages immediately * PHP 5 users do not have to change their code when a PEAR package "goes 5" Comments? - Stig