prefix, mature outsiders and some brainstorming for PEAR2

Hi, I am just brainstorming here, though this mail is obviously spawned from the Doctrine naming discussions. I am very much of the opinion that we need a prefix to protect users from things like the Date and File mess. As PHP gets more native OO code we will have more and more clashes. The same applies to issues between user code or other library repositories. I also think it would be wise if we are able to integrate mature outside packages like Doctrine. Its obvious that any package coming in has to adhere to our standards. There is no way around it. Period. But obviously we define out standards and so we should make sure that whatever we do, we should not make it needlessly hard for above mentioned mature packages. The problem is that these mature packages have existing communities. These packages may even have stable releases already (btw: Doctrine does not as of now). Moreover they will usually have already solved the potential for naming collisions. So the name Doctrine already protects the classes from naming collisions. There is another thing here. We do not allow redundant packages, but we do allow redundancy in functionality if a different approach is taken. This will inevitably lead us into situations where the obvious name is taken. People have been clever in working around this in several case especially in the Database category. So we have DB_DataObject, DB_Table and DB_Querytool. In the case of LiveUser we ended up having to work around the existance of Auth and so we invented a name just to be able to include the code into PEAR. But if some packages have a prefix and others don't its confusing if you are writing an autoload implementation for example. If you make the PEAR_ prefix part of the package name for packages with non-invented names its also messy. So the conclusion is that either the original author accepts breaking BC or he is out? It also means that if we do accept invented names, but require PEAR_ postfix these packages will end up with fairly long package names. Then again Doctrine is an example of an already very long package name to begin with as PEAR_ORM would be just as long, but would include the PEAR_ prefix. I do not have any for how to handle naming collisions between packages which are functionally redundant but with different implementations. I guess the second guy will continue to have to either find a clever alternative or add an invented name. So I guess the conclusion to my stream of thought is that Konsta will have to accept a rename to PEAR_ORM or similar or Doctrine simply does not make it into PEAR. The same applies to all other mature packages out there. Anyways I just wanted to bring this topic up as there is still this idea floating around for a version 2 of the PEAR repository with a clean namespace and some potential for regulation changes. regards, Lukas