Re: [PEPr] Comment on RFC::Prefix all packages with P_

Hi Pierre, Pierre-Alain Joye wrote:

However we have to find a solution to use common names and reserved words as class/function names (File, Image, etc...).

Note: I am using Date here as an example only because I know of a dependency off the top of my head. So we update Validate to P_Validate, but Date hasn't been updated yet. What does P_Validate now optionally depend on? It can't depend on P_Date because it doesn't exist yet. So P_Validate is released (with a Date dependency) and later Date is changed to P_Date. Now P_Validate has to be re-released. Now what happens if there are two dependencies? three? There will be releases flying out all over the place. And what about the packages that depend on Validate now? They will all have to be re-released at least once, if not every time P_Validate is now released. Also, look at your file system after installing P_Validate. You have basically duplicate files with different names and a few non-functionality-enhancing changes. Now update a few other packages. There will be lots of files sitting around causing confusion and more potential problems, not to mention just using up disk space.

Not that the prefix will be added in the next major version of a package. For example File will be renamed to pFile, P_File Pear_File or whatever_File ;)

OK. So again, what will this actually solve then? When will the next major release of File be? Will there ever even be a new major release of File (other than to comply with this RFC)? This RFC will make it so that all new packages and packages that are released with a new major version are prefixed with whatever_. Existing packages that don't have a new major release will remain as they are. Then we have two different naming conventions. That will just cause confusion and headaches. Now consider PEAR::DB. This package has one of the highest probabilities of causing problems in the future and it is deprecated. It will not have another major release. Therefore, the conflict will never be resolved. Again, this RFC proposes a solution to a problem that doesn't exist. If the problem doesn't exist, why are we trying to fix it? We end up fixing something that doesn't need fixing and at the same time creating several _real_ problems. -- Scott