Re: RFC: PEAR Changes / Scope

From: Date: Sun, 11 Nov 2001 15:39:25 +0000
Subject: Re: RFC: PEAR Changes / Scope
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-2805@lists.php.net to get a copy of this message
At 04:43 PM 11/10/01 -0600, Lux wrote:
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 think PEAR will one day reach a size where the whole of it can't be distributed with PHP (isn't this the case at the moment?) so we will have to do something... I'll leave it up to the rest of you to decide what :-)
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. ;)
The arguments used have convinced me that we need a standard of one or the other. I've always used tabs, but I'm currently experimenting with spaces, and it's not too bad - except the backspace needs pressing more often.
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.
And which is harder - reading "$obj->method($p1, $p2);" or switching between styles when working on a project? In the colour coding editors spacing isn't such a problem. So I propose we stick to the standard.
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.
Wrapper.
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.
Well, I would prefer them all to go on the same line as the code: function functionName () {
        fooba();
} because I find that much more legible. So I guess I'm saying I want this standard changed, as I can't see the reason for it (unlike spaces instead of tabs) Regards, Peter. ---oOo--- sendcard - *The* PHP e-card solution http://www.sendcard.f2s.com/ ---oOo---

« previous php.pear.dev (#2805) next »