Re: Expect more!

Hi, +1 This proposal is the most sensible I've heard. To have a repository for all php snippets connected with php.net would be very useful. As it is, when I am wondering whether a great solution exists for a problem I have, I first check large repositories of non-dependent code like phpclasses, phpbuilder, even zend.com, and of course also PEAR. I'd be more inclined to check PEAR first if there were two repositories the way Jens describes, and it would make a lot of sense to organize the best of the best by user downloads (popularity) as well as what php.pear.dev thinks. In other words, I want to know which classes are most used, and I will always try them first. The way PEAR is organized now, this is difficult to do. For my needs, very rarely does a utility class do what I need, and often is not flexible enough to be changed for my needs. Having many options available would be a good thing for people who have problems that the original developers of the best coded classes never anticipated. I am biased, of course. I started using PHP because it is SO much more flexible than the other options I've used for web backends, and I started developing phpDocumentor last April because it was more flexible than the other programs out there. I strongly believe that the flexibility coded in phpDocumentor is the sole reason for its success, and would like to see more of that in PEAR. The main problem I think PEAR should be solving is making it easier for people to re-use code. Jens's suggestion seems a welcome addition. Greg "Jens Vonderheide" <vonderheide@redlink.de> wrote in message news:BIEJIIHBBHNFOHIDEBAMIEEBINAA.vonderheide@redlink.de... > > Then so be it. In my opinion, it takes more skill to contribute to > > someone else's package or two merge two packages then to just wrote > > something from scratch and add it to PEAR. In the end both the > > developers and the users well benefit more from fewer better packages. > > Ofcourse new packages are welcome as long as they add new functionality > > to PEAR. > > I think we have two distinct problems here: > > 1) The need for a central PHP code repository like CPAN for Perl. > Right now, we have a lot of web sites that have some code, but finding > some existing PHP code for a problem is really a hassle. If I don't find > anything on PEAR and some other selected sites, I usually go and write > it myself. Reinventing the wheel can be much faster than finding the > one shop that has exactly the wheel you need... > That's what I like about CPAN: If I can't find Perl code there for my > problem, I can be quite sure that no such code is available. And if an > INSTALL file tells me to install Algorithms::NPCompleteSolver, I know > exactly where to find it and how to install it. > > 2) The need for good and reliable classes that developers can use > without much thinking about bugs, backward compatibility and the like. > > Because these really are two problems, I suggest two solutions to it: > > 1) Create a central repository with a common installer (i.e. PEAR) and > let people dump code there freely and without any approval at all. > Any developer who wants to use such code must know that he needs to > check the code thoroughly before. > And yes, let there be 10 implementations of the same solution. If anyone > felt he needed to write a new implementation, even though there already > were some, he would probably have some good reasons for it. > > 2) Take the best (best being defined in terms of stability, ease of use, > whatever) and mark them such (but them in a special part of the repository, > give five golden stars, you name it). Use the community voting process > suggested in this thread for it. > These classes can be used by developers without much thought and can be > expected to be available on most systems. > > Just be .02 Euro, > > Jens