Re: RFC: PEAR Changes / Scope

I've been out of the loop for almost a week, trying to catch up with the discussion now... Lux wrote: > > > As I said multiple times: I'm open to changes. I would be very > > happy, if you could set up sth. like an RfC describing a less > > strict coding standard that you think is good for PEAR, since I > > currently don't have the time to sit down and write something > > down in a proper way. > > > > I'm very sure, that lots of other people on this list are very > > interested in improving the guidelines, so there will be > > comments on your work for sure. > > > > - Martin > > Alright, quick RFC (sorry, don't have time to prepare a formal one either): > > 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 > compared to Perl's CPAN. > > 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. What's been discussed before is giving certain packages a "core" status and making a separate distribution of this. The suggested name is PFC, "PHP Foundation Classes". The only things I see a need for "splitting", or rather, "partitioning", are: * extensions taken out of PHP itself (pear/PECL dir in CVS) * Gtk classes (since they follow separate conventions) * applications, if we will host any > 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. ;) I have problems justifying to myself spending hours on discussing issues like this one. Can't we all just decide on something and move along? (I'm fine with all spaces like today or 4-space tabs, just to be able to move along). > 3. Use ample spacing. I prefer using the "$obj->method ($p1, $p2);" > syntax while some prefer "$obj->method($p1,$p2);". As long as its > legible. I'll stick with my way, you stick with yours. There will > always be a level of subjectivity about this that will creep its way > into the approval process for classes. That's fine, but I think we > should just say "as long as it..." instead of "it has to be" regarding > spacing. > > 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. Method naming seems to be the single most controversial issue in PEAR. As much as I think it's amazing that some people invest so much hard-felt emotion in this issue, we do need a standard here. I think your suggestion is good, "core" stuff has to be strict. > 5. Where to put curly braces. I say CORE stays the same, but EXT, > 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. > Good. As long as you and I are both stickler enough about our ways of > doing things, it encourages diligence, which is required. Agreed. > 6. Instead of "it has to be this way", why don't we add (on top of the > initial "as long as") "it has to be consistent throughout a class or > package". This should help ensure code consistency. Fine :) > 7. Let's try to use single-quotes whenever possible. I tested a script > I wrote that had tons of quotes in it both ways, and it made a > noticeable difference. We have to stay the fastest bad-asses on the web > dev scene, after all. ;) As much as I've tried, I have not been able to notice a speed difference in PHP 4. > The rest of the standards I'm quite happy with, so if anyone wants to > add to this about issues they have, cool. I also want to clarify, I'm > not saying let's go changing the CORE stuff now, it doesn't need to be. > There's no reason to. So with the changes I'm proposing, existing > apps using PEAR will be unaffected. Also, the benefits of a centralized > 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." "PEAR extensions library" is redundant, "PEAR" is enough. :-) - Stig