Re: PEAR Changes / Scope

> 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. heh, binarycloud's structure: base/core/ Base Classes base/mgr/ ext/ metabase/ pear/ ... etc. (note the CORE and EXT directories) I agree with you but not here. Anyway, I don't think that necessarily fits in with what PEAR is trying to achieve. A collection of high quality classes. > 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. I agree that there should be some basic 'common' code available with the PHP Distro, but I think the PEAR installer is much more important. Ease of installation will bring use, and there should be no large brick wall between "core" classes and "ext" classes. Who makes that decision? You? Stig? The "committe"? > 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 tend to agree here... or better said I prefer to have simple tools to standardize with. Personally I prefer 4 spaces but if someone likes tabs, who cares? > 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. Agreed. Trying to force that kind of minutae on people is unrealistic with a large base of code. I like the "as long as there's ample documentation and the code is clean and legible" route. > 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. We _do_ do that in binarycloud, throughout. Pain in the ass otherwise. But we use plenty of other code that doesn't adhere without a problem. It's really more a question of consistency and style then real utility. Never had a problem with smarty method naming. Can you really say that Smarty->Display is much better than smarty->display? I can't. I like the first better, too :) > 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. I disagree here. It really affects the way you read the code. > 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. In general I agree there. > 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. ;) I've never noticed any _speed_ difference but it is good to be in the habit of using " only in situations where you want to explicitly declare a value to "be interpreted" by PHP. > 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." It seems like I see this question every 2 weeks. Isn't there a declaration of the PEAR purpose somewhere? Everyone seems confused: "is this a platform? a library? a set of libraries? a set of applications? a really shiny espresso machine that will make you fantastic espresso, shine your shoes, and portscan your machine?" I think a single, 1 paragraph statement on the purpose /intent of PEAR would be really helpful. Yes, it is in the new FAQ: ----------------- The PEAR concept it self is only a Repository, a unique web repository and the works done in this area (pear web and pear installer/packager) are in this direction. Also it's not a common repository, is a repository with software that: has been approved to be in by the Pear developers and has the general concensus of the Pear community (Pear users) follows a unique coding standard (avaible to read, already standarized and used in all PEAR) uses a common error handling mechanism tries to have a similar way of use has documentation about its API in the PHPDoc format has documentation/examples/tests (to be marked as stable -------------------- I think that leaves quite a bit open to question. best, _alex