Re: future of PEAR (was [PEAR-DEV] [Call For Votes] PHP::Fork)

Alexey, I don't think we would need to start over. I do think we could seriously justify some major changes with the release of PHP 5. PHP got much better, why can't PEAR? Also, there is no reason to replace the existing PEAR with a new PEAR. Those who use PHP 4 will continue to benefit from PEAR for a while. Those who wish to live in the next century will use the newer PEAR. PEAR should also plan for PHP 6, and PHP 7, making it easy to handle these when they come. A little foresight goes a long way. Some of the issues that I would like to see start over include: -- error handling. PEAR_Error is bloated and slow, difficult to use, and way too complex for most experienced programmers to grasp how to use it. I would like to see a stack-based implementation of errors for non-exceptions like warnings/notices, and PHP 5 exception class used. Error raising AND handling for most cases should weigh in at under 200 lines with comments. All error raising code should fit in under 200, and only complex error handling that also manages PHP errors should take up more than that -- PEAR base class is too general-purpose. Drop destructors, for one. -- naming. For channels to work, all PEAR packages should be prefixed with PEAR_. BC issues should also be taken into account with naming -- cross-package API. All packages within a category should share a common API, so that it is relatively simple to switch from similar package to package (DB_NestedSet to XML_Tree's DB driver, for instance). This would also solve the issue of redundancy. If a better way to do something comes along (Cache_Lite vs. Cache), a common API will allow people to switch from one to the other much more seamlessly than now. -- political issues in the structure of maintainers and of PEAR group. PEAR group has too much responsibility, and no time to enforce it. packages with critical bugs remain untouched because there is no easily defined way to handle unmaintained packages, etc. etc. It would be nice if PEAR group was somehow accountable to the rest of PEAR as well. A study of functional political entities in the programming world and in the real world would be informative. Greg Alexey Borzov wrote:

Hi! Tobias Schlitt wrote:

On Mon, 2003-11-10 at 21:35, Alexey Borzov wrote:

What exactly prevents adding this "community process" or whatever to the current PEAR?

What actually prevents us from creating a new pear to even better handle upgrade to PHP5 and repair some definite technical issues, etc.?

"You heard that? PEAR was so broken they had to start it all over! I am not touching the thing with a 10 feet pole!" Please enlighten me, what are these "definite technical issues" that cannot possibly be fixed in the current verion?