Re: RFC: PEAR Changes / Scope

Alexander Merz wrote: > > 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. As long as the package and release are registered on pear.php.net, you can download them from SF or wherever (we want mirrors, right?) But without registration in our database, it'll all fall apart with name conflicts and chaos. > > 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. We intend to bundle a set of PEAR packages with PHP, but how much more than the installer support stuff I don't know yet. Maybe we'll bundle the "PHP Foundation Classes" when time comes. > > 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. I'm going to let you guys fight this one out. :-P > > 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." See my comment on SF above. - Stig