shortcomings fully realized
Posted: Fri Apr 09, 2004 10:17 am
Hi,
I am one of the core developers of the PEAR package who has joined the game relatively late. I see the strengths of the PEAR installer as the reason PEAR will become an important force. The base PEAR class is one monstrous mistake, and PEAR_Error is pretty close. Everyone knows this. I designed an error class that is much, much more flexible and it is part of PEAR 1.3.1 (PEAR_ErrorStack) - check it out.
Unfortunately, for classes to be compatible, error handling really must be the same, and it must be easily managed. We all hope to be able to use exceptions for the majority of errors in PHP 5, but exceptions are still not useful for spitting out debug information, or warnings/notices, and that is why PEAR_ErrorStack will be a useful thing - it can return an Exception class (or any subclass), and it also is useful for debugging. Best of all, it's much faster (including the require_once) than PEAR_Error, so it will make it worth developer's while. Also, unlike PEAR_Error, it's open to criticism at this stage, so if you want to see the standard repository improve, try it out and make suggestions.
But enough about details.
The first thing I believe in is choice, which may differ a bit from the PEAR conventions. For this reason, I've been pushing a new feature for PEAR 1.4 called "channels." This is similar to what you associate with television or other class repositories. Each channel contains a unique virtual namespace, so you can have conflicting package names with PEAR, and it won't overwrite conflicting php files on install. This also means you can have more than one master server, and a search path through them - very good for promoting competition, imo.
It will take some time for PEAR to move into the new millenium, but that doesn't mean you can't have other repositories that will forge ahead and still inter-operate. It is better for PHP and that means it is better for all of you and for me if there is some consistency between great packages and applications.
If you really want to see PEAR improve, the best thing you can do is to make some noise on pear-dev in support of requiring test cases and documentation to be marked "stable," and to make your needs known. The climate of pear-dev has changed remarkably since lastcraft noted the rot in the culture, mainly because developers like you have made their needs known.
Like it or not, PEAR has "php.net" in its URL - if you don't like it, silence will only convince those who don't see the light that they are right about what is needed.
Incidentally, I'm in favor of PEAR being a library that has packages that are easy to use in the same application and NOT a framework, in case that wasn't obvious :). However, I could see it containing frameworks at some future point if the duplicate package requirement is lifted.
Regards,
Greg
I am one of the core developers of the PEAR package who has joined the game relatively late. I see the strengths of the PEAR installer as the reason PEAR will become an important force. The base PEAR class is one monstrous mistake, and PEAR_Error is pretty close. Everyone knows this. I designed an error class that is much, much more flexible and it is part of PEAR 1.3.1 (PEAR_ErrorStack) - check it out.
Unfortunately, for classes to be compatible, error handling really must be the same, and it must be easily managed. We all hope to be able to use exceptions for the majority of errors in PHP 5, but exceptions are still not useful for spitting out debug information, or warnings/notices, and that is why PEAR_ErrorStack will be a useful thing - it can return an Exception class (or any subclass), and it also is useful for debugging. Best of all, it's much faster (including the require_once) than PEAR_Error, so it will make it worth developer's while. Also, unlike PEAR_Error, it's open to criticism at this stage, so if you want to see the standard repository improve, try it out and make suggestions.
But enough about details.
The first thing I believe in is choice, which may differ a bit from the PEAR conventions. For this reason, I've been pushing a new feature for PEAR 1.4 called "channels." This is similar to what you associate with television or other class repositories. Each channel contains a unique virtual namespace, so you can have conflicting package names with PEAR, and it won't overwrite conflicting php files on install. This also means you can have more than one master server, and a search path through them - very good for promoting competition, imo.
It will take some time for PEAR to move into the new millenium, but that doesn't mean you can't have other repositories that will forge ahead and still inter-operate. It is better for PHP and that means it is better for all of you and for me if there is some consistency between great packages and applications.
If you really want to see PEAR improve, the best thing you can do is to make some noise on pear-dev in support of requiring test cases and documentation to be marked "stable," and to make your needs known. The climate of pear-dev has changed remarkably since lastcraft noted the rot in the culture, mainly because developers like you have made their needs known.
Like it or not, PEAR has "php.net" in its URL - if you don't like it, silence will only convince those who don't see the light that they are right about what is needed.
Incidentally, I'm in favor of PEAR being a library that has packages that are easy to use in the same application and NOT a framework, in case that wasn't obvious :). However, I could see it containing frameworks at some future point if the duplicate package requirement is lifted.
Regards,
Greg