Search found 12 matches

by lsmith
Tue Apr 13, 2004 8:08 am
Forum: PHP - Theory and Design
Topic: Come to the PEAR-fest
Replies: 52
Views: 76887

In summary I will take all of your comments and while I dont agree with some, feel that we already have resolved or are about to resolve others there is obviously value in all your suggestions. I will see how things will go and how PEAR will evolve. Knowing the world is not black and white it still ...
by lsmith
Tue Apr 13, 2004 7:48 am
Forum: PHP - Theory and Design
Topic: Come to the PEAR-fest
Replies: 52
Views: 76887

Well maybe this is an extreme example, but in order to have this level of protection for MDB2 I would assume to require about 400-500 test cases. You would only need test cases for enforcing features that you would want to keep. Also, with respect, that is an exaggeration. I have built object persi...
by lsmith
Mon Apr 12, 2004 12:59 pm
Forum: PHP - Theory and Design
Topic: Come to the PEAR-fest
Replies: 52
Views: 76887

1) If PEAR wants to be a class library (it obviously does) then how about promoting the phpclasses site into the php.net domain. Yes I know Manuel can be an ascerbic **** at times, but he has done more to build a PHP community than just about any other single person, as well as being a highly skill...
by lsmith
Mon Apr 12, 2004 12:29 pm
Forum: PHP - Theory and Design
Topic: Come to the PEAR-fest
Replies: 52
Views: 76887

lastcraft wrote: 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.
Of course PEAR was not the sole driving force. Anyways I didnt make this comment to start a smurf contest :-)

What I wanted to say is that PEAR does have a certain amount of influence on internals@ and that we pushed for a fair amount of features to get in.
lastcraft wrote:
lsmith wrote:So what is a redundant package?
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.

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.
Yes and all of the reasons stated above (we wouldnt allow a procedural interface due to namespacing issues, which could easily be fixed by putting a class around a bunch of methods that can be called statically .. yeah lame but what can you do if the feature is missing from the language) sound like valid reasons for a "redundant" package.

We have Cache and Cache_lite for example.
We have DB and MDB.
We have have multiple template engines (well PHPLIB, IT[X] and Sigma are a useless redundancy .. but if you flame hard enough any opensource has a hard time to keep itself clean)
lastcraft wrote:
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.
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.
Well we are a library of loosly tide packages and we never closed any field to anyone else.
lastcraft wrote:
lsmith wrote:We are taking a very different approach in our current effort to build up a QA team.
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.
I dont know if you read the actual QA team RFC, but the QA is more about assisting maintainers. But at the same time they are sort of a means to ensure a checks and balances between the users (and their bug reports) and the control over a package that a given maintainer has.
lastcraft wrote:
lsmith wrote:However I dont agree that error handling should not be handled inside the libs. Handling it outside is impossible.
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.

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.
I dont follow your argument at all. The PEAR error handling doesnt handle logging. Thats why there is a separate package for that in PEAR. Its entire purpose is to ensure that there is a standard way to handle error codes, error messages in order to allow the creation of handlers that work across all packages.
lastcraft wrote:
lsmith 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
There were plenty of people clammoring for exceptions outside the PEAR community too. It's nice to hear that they didn't get heard :(.
[/quote]

See above. I wasnt claiming that.
by lsmith
Sat Apr 10, 2004 4:09 pm
Forum: PHP - Theory and Design
Topic: Come to the PEAR-fest
Replies: 52
Views: 76887

As I have stated we are an apache sub-sub project. As such we are actually very lax in our licensing, but we have clear limits. Also we agreed that we want the licensing to be more or less in line with PHP's.

See this announcement for details:
http://pear.php.net/group/docs/20040402-la.php
by lsmith
Fri Apr 09, 2004 3:31 pm
Forum: PHP - Theory and Design
Topic: Come to the PEAR-fest
Replies: 52
Views: 76887

Ah yes .. I was temporarily confused suggesting the relicensing. Once the channel support is in someone else can start a GPL project. However technically we actually probably need to use the Apache 2.0 license, since we are a php subproject and php is an apache subproject. Ah well. I am sorry to say...
by lsmith
Fri Apr 09, 2004 12:51 pm
Forum: PHP - Theory and Design
Topic: Come to the PEAR-fest
Replies: 52
Views: 76887

Just so you dont get your hopes up. Channel support will allow people to provide their own channels. However I dont see a PEAR GPL channel on the horizon. However I still dont quite understand your argument. Essentially I am saying what the people said to FSF after their criticism of the apache 2.0 ...
by lsmith
Fri Apr 09, 2004 11:33 am
Forum: PHP - Theory and Design
Topic: Come to the PEAR-fest
Replies: 52
Views: 76887

I am no licensing expert. But all of the allowed licenses allow you to redistribute the code under a different license as long as you keep the credits intact. So I dont really see a problem. However if we would allow GPL'ed packages this would effectly make it impossible to distribute the packages a...
by lsmith
Fri Apr 09, 2004 11:06 am
Forum: PHP - Theory and Design
Topic: Come to the PEAR-fest
Replies: 52
Views: 76887

However you dont need the installer. I generally bundle all PEAR packages with my application. Then your applications must not be GPL'd - mine are, and while bundling an incompatibly licensed package with it would be legal, it would present a confusing situation for the user.[/quote] No they are no...
by lsmith
Fri Apr 09, 2004 11:02 am
Forum: PHP - Theory and Design
Topic: Come to the PEAR-fest
Replies: 52
Views: 76887

Hi, lsmith 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...
by lsmith
Fri Apr 09, 2004 10:03 am
Forum: PHP - Theory and Design
Topic: Come to the PEAR-fest
Replies: 52
Views: 76887

Ah I forgot to talk about the installer. Its definately becoming more and more mature. Actually I would never have thought this to such a challenge but its not such a trivial process. However you dont need the installer. I generally bundle all PEAR packages with my application. Back in the day we ha...
by lsmith
Fri Apr 09, 2004 9:54 am
Forum: PHP - Theory and Design
Topic: Come to the PEAR-fest
Replies: 52
Views: 76887

Hi, I have briefly looked at some of the comments and I am in a very unique position to shed some light on things. 1) I am a member of the PEAR Group 2) I am also the lead developer of MDB As such I am very much involved in what goes on in PEAR and I am also someone that came with an alternative to ...