Posted: Sun Apr 11, 2004 10:35 pm
Hi...
Firstly thanks for taking the time out to respond.
The web is not a Perl world anymore.
Also some existing packages just aren't very good. The only way to fairly oust the incumbent is to develop the new one along side.
Besides, what is actually wrong with a redundant package? What if both apd and XDebug were in PEAR at the same time for example? Does the sky fall in? You won't get thousands of packages if the barrier to entry is one of minimum quality and usage.
It worries me that these two things are being mixed together. Are we going to end up with another framework style solution here with a PEAR error class having to know about lot's of additional resources and so forcing it's own inclusion? This has a ring of deja vu. A dependency injection approach (PHP5 now has interfaces after all) would be so much more flexible.
.
Firstly thanks for taking the time out to respond.
I hate to start on a bad note, but I have to say I simply don't buy this. PHP3 and PHP4 had already started on the OO road without PEAR. PHP5 is a continuation of this and necessary to compete with .NET and to leverage Java designs anyway. Also there is a lot of OO stuff that is not needed by PEAR (final - why?) or anybody else. I would say Java has more infulence on PHP than PEAR judging from the result.lsmith wrote:One thing that alot of the people bashing PEAR.php fail to take into account is that PEAR is one of the main reasons why are getting all these nice features into PHP5. So its kind of lame to be attacking PEAR that its a poor-mans PHP5. Without we will not be having the PHP5 we are having now.
The web is not a Perl world anymore.
That's just the problem. There all sorts of reasons why one package may be better than another, ranging from simplicity, performance, support for procedural approaches, conformance to an industry standard and many others. It would be a lot easier to decide which packages are redundant once they have spent some time in the library. Doing it at the proposal time is impossible.lsmith wrote:So what is a redundant package?
Also some existing packages just aren't very good. The only way to fairly oust the incumbent is to develop the new one along side.
Besides, what is actually wrong with a redundant package? What if both apd and XDebug were in PEAR at the same time for example? Does the sky fall in? You won't get thousands of packages if the barrier to entry is one of minimum quality and usage.
Which is the nub. Is PEAR a core library (STL, boost) or is it a package repository (CPAN)? PEAR should decide and then open up the other field to something else. These goals are diametrically opposed.lsmith wrote:It was pointed out that a good core library needs to be driven by a core developer tema instead that can work on any part as they see fit.
This is another god view way of doing things. Quality is an impossible characteristic to judge and open to even more abuse than before. Evolution and self selection would shift the problem.lsmith wrote:We are taking a very different approach in our current effort to build up a QA team.
This is not true if we stick to error handling. Error handling is not the same as logging however which is a more complicated cross cutting issue (the usual clean way to deal with logging is to attach a logging decorator around the observed object). Good error handling means that you actually have to log less information. The target of the logged data is also up to the application, in the same way an error handler should be.lsmith wrote:However I dont agree that error handling should not be handled inside the libs. Handling it outside is impossible.
It worries me that these two things are being mixed together. Are we going to end up with another framework style solution here with a PEAR error class having to know about lot's of additional resources and so forcing it's own inclusion? This has a ring of deja vu. A dependency injection approach (PHP5 now has interfaces after all) would be so much more flexible.
There were plenty of people clammoring for exceptions outside the PEAR community too. It's nice to hear that they didn't get heardlsmith wrote:Of course PHP5 opens new possibilities, but remember again that PEAR was one of the main groups of people making sure that exceptions have made it into PHP5