Re: PFC-RFC

"Jason Lotito" <jason@devnetwork.net> wrote in message news:3E5AAC52.4040807@devnetwork.net... > > - PF Classes do not break BC without giving the user enough time to > change > > its code. Meaning, there should be some releases between non-BC API > > changes with the new and the old behaviour integrated (if possible) > > That's an independant developer decision I think. If a major API change > is going to happen, then probably a major version increase is in order. > If the developer needs to make a change to a PFC API, then he makes > the change. Granted, PF classes shouldn't need to be changed often, or > else they weren't designed properly from the beginning. Any project worth beans will provide warnings before breaking BC. This is one of the marks of a project that is written for the endusers and not just for the original developer. > > - PF Classes should only depend on PF Classes. > > > > And if the PF Class needs to depend on a class that isn't in the PFC? > It should use a PEAR then. The needed functionality should NOT simply > be included. This is not a problem, as Christian says, the needed functionality should be upgraded to PFC quality. Nothing PFC-related need happen overnight, and in fact it would be unwise to rush things of this nature, as then BC becomes a serious problem (for reference, see anything written and released by Microsoft). > > - If the Packages shows enough downloads and active developement in the > > last months and was peer-reviewed, it can apply for a PFC. There's a vote > > on pear.php.net about giving the PFC badge to a class or not (I'm not > > sure, if it really neads a vote as long as noone gives his/her veto on > > pear-dev.) > > The number of downloads should have nothing to do with whether a class > gets a PFC badge or not. The quality of the code is what is important. A perfectly written class that has no value to the majority of users should not be included in PFC. A class that, for example, translates to Klingon from Swahili-based XML may not have general interest, and would not belong in PFC. Of course, I mean no offense to any Klingons actively using PEAR. > If it's a class that is good and solid, then it should be included. A > vote by other PEAR developer's is a good idea. A vote in the negative > should be taken seriously and considered. Majority rules, but minority > rights. =) Deevloper A may get +10 votes because everyone likes him, > but gets -2 votes from 2 people. Why? Maybe they are right. It must be possible for the +10 people to override the -2 people, to keep zealots from dominating discussions. Perhaps a system of override (++1?) would work. The strengths and weaknesses of other PHP communities should be examined as well as the strengths of CPAN. For instance, the ability to add user comments to the package description page at pear.php.net could be a tremendous benefit, similar to the PHP user manual online. Christian's proposal makes a great deal of sense to me. Having a semi-closed system with extreme quality and careful consideration as its hallmarks can only be good. Pairing this system with an open repository can only be better. PHP thrives ONLY because there are many different kinds of people who find it useful. One other consideration I would like to see in a PFC: all classes in PFC should be designed to allow controlled modification. This could be through class newclass extends PFCclass, or through some other interface, but by assuming the class will not be used as it is, and will need extension is very important. Perhaps part of being a PFC is a well-documented method for extending the class as well. Even more interesting to me would be the possibility of interfacing unrelated PFCs. This is not a requirement, but being able to integrate projects like LiveUser and HTML_QuickForm would certainly appeal to me a great deal. I've been working on a class that works as a registry of existing objects, allowing unrelated objects to communicate through well-defined interfaces, similar to event handling but not reliant on user input necessarily. Perhaps something like this would be useful as/in a PFC? Greg -- phpDocumentor http://www.phpdoc.org