Re: RFC: PEAR Changes / Scope

First of all, lets check the basics of PEAR: 1. to provide a consistent means for library code authors to share their code with other developers 2. to give the PHP community an infrastructure for sharing code 3. to define standards that help developers write portable and reusable code 4. to provide tools for code maintenance and distribution > 1. I propose that PEAR be split into CORE and an EXT (or CONTRIB), where > CORE is the stuff we've already got, and the stuff that has to go > through a rigorous approval process. Basically, Java's standard > library. EXT would be code that conforms to a certain level, but less > so than CORE. Duplication would be allowed in EXT, but we would still > be talking about classes, not apps or forums or builders. EXT could be And the advantage? Please check the "php4/pear/ vs. pear/"-problem. EXT would break #1 and #3. If you won't follow the standards, then go to Sourceforge, you can create a package.xml and you can install your package with the pear-installer from Sourceforge. There is no need to distribute them from pear.php.net. > I like the idea someone just had on here about distributing the CORE > with PHP, but not EXT. Perl does this, and it works very well. This is only a distribution problem, no PEAR problem, you are free to create a PHP-dist, which include common used PEAR-packages, like Perl does with common used CPAN-packages. > 2. Tabs vs. Spaces? Who cares. As long as either tabs or 4 spaces are > used, it's all good. Tab length can be set in almost any modern editor, > and 4 spaces is already the PEAR standard. I don't think a few rebel > classes with tabs are going to completely overturn the system. ;) Breaks #1. It will be horrible, to change the setting of my editor to match the prefs of the author to get readable code every time, when i open a new file. > 3. Use ample spacing. I prefer using the "$obj->method ($p1, $p2);" ... > should just say "as long as it..." instead of "it has to be" regarding Coding Standards: "... should be..." > 4. Method naming should probably be standardized in the CORE. So > methodName () it is. But as for EXT, if the class has an established > user base, it is unrealistic to ask them to change. method_name () > isn't all that bad anyway. Take a look on the FAQ: "If you write a new class, try to keep API compatibility with existing classes as far as possible! If it isn't possible to keep the class compatible himself, try to create a wrapper class to keep compatibility. Don't care, if this wrapper needs a lot of time or memory, a wrapper class only has to keep compatibility and make migration easier." > whatever. It comes down to coder productivity. I've been doing things > this way for X years, you've been doing them that way for Y years. And? What happends if your hired by a company, which have another coding standard then you prefers? > place for EXT classes to go is that a project can say "we rely on > classes X, Y, and Z, which are available from the PEAR extensions library." A lot of projects already say: "we rely on > classes X, Y, and Z, which are available from the Sourceforge."