Re: prefix, mature outsiders and some brainstorming for PEAR2

Lukas Kahwe Smith wrote: > 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. This is not really an opinion, the PHP coding standards state clearly that all classes from henceforth will be CamelCaps with no _ (underscore) in the name - and that PHP reserves the right to take *any* name that fits the needs of PHP. As such, any class name without a _ (including PEAR) is not available. Unless we want to be stupid again. > 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. Rock and a hard place. > 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. This is not protection from naming collisions, there is no _ in the name. I jumped into the long discussion on php-internals about this issue, and Marcus Boerger pointed out the specific coding standard from http://cvs.php.net/viewvc.cgi/php-src/CODING_STANDARDS?view=markup "[7] Classes should be given descriptive names. Avoid using abbreviations where possible. Each word in the class name should start with a capital letter, without underscore delimiters (CampelCaps starting with a capital letter). The class name should be prefixed with the name of the 'parent set' (e.g. the name of the extension). Good: 'Curl' 'FooBar' Bad: 'foobar' 'foo_bar' " This is quite clear - any class without "_" is potentially at risk, and PHP internals explicitly does not reserve classes with _ in the name. Ilia commented on our original PEPr proposal to define a prefix here: http://beeblex.com/lists/index.php/php.pear.dev/43465 > 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. ... and this is one of the major long-term problems in PEAR at the moment. > 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 don't we can have both descriptive package names and efficiently typed classnames. I would also like to remind everyone that classnames are rarely typed in proper programming, except to do: $thing = new This_Long_Name() and for class constants/static functions. The only possible hit is that zend_hash has to do a bit of extra work and is therefore slightly less efficient when the classname is longer than 15 characters because all of the good hashing algorithms are GPL and PHP can't use them. > 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. ... and this is one of the major problems in PEAR at the moment. > 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. I see three possible paths here: 1) PEAR needs to stop doing the same thing it's always done and instead investigate where it can be most useful to users. Do we need to become a competitor to Cake/Solar/Zend Framework? Do we need to concentrate on providing missing functionality in specific PHP versions? 2) PEAR can stop trying to be a package repository with rule upon rule (i.e. stop distributing packages altogether), and simply focus on unifying the way packages are installed across PHP-dom from other channels and sources, so that one can interface and easily manage dependencies between disparate sources. 3) Keep doing the same thing I don't see any way that we can do #1 or #2 without a clean break from PEAR and pear.php.net. This means a separate installer and a new website with another domain. Either pear2.php.net, pyrus.php.net, whatever. Without a re-branding and a clean break with new rules and political structure, there is no chance in hell that PEAR will ever be both a locus for stable AND innovative PHP software. I can imagine a world where we include Doctrine without name changes, and *host it from their own channel*. In this world, we would make sure that it is completely compatible with the PEAR Installer 2 (whatever it is called) and allow cross-channel dependencies simply because we are allowed to have enough control over the release and development process such that it won't break anything. In this world, PEAR would focus on integrating useful tools and provide things like interfaces that external projects should implement in order to cross-polinate. Or, we can try to become the central focal point for all PHP 5/6 packages and installation, just as PEAR tried to be the central focal point for all PHP 4 packages. In fact, PEAR really hasn't changed much at all since this crusty old introduction was written: http://pear.php.net/manual/en/introduction.php The obvious changes in that text are "XML-RPC" should be "XML-RPC and REST" and "PHP 4" should read "PHP 4 and PHP 5." The sub-repository part is outdated as well. These questions I've raised are just too sweeping to be decided simply by a measly PEPr vote - they require some kind of real governing body for PEAR to make decisions, and so my next message will be proposing some changes to PEAR that will allow these questions to be decided with some reasonable speed and perhaps intelligence as well. Thanks, Greg