Re: HTTP Class

From: Date: Fri, 05 Jan 2001 21:57:04 +0000
Subject: Re: HTTP Class
References: 1 2  Groups: php.pear 
Request: Send a blank email to php-pear+get-802@lists.php.net to get a copy of this message
Quoting Manuel Lemos <mlemos@acm.org>: > In PEAR repository it is assumed that there is only one way to do > something right. In PEAR repository there seems to be only space for one > class of each type. This leaves absolutely no space for others to come > with different approaches to do the same. > > For instance, it would be impossible to have in PEAR repository 8 page > template classes or 6 table wrapper classes like there are at the PHP > Classes. I see this simply as a matter of differing approach. The question is, how does the user figure out which class to use? I find Perl's CPAN quite confusing sometimes, because there are such a wealth of classes to download, many of which do the same things. With this in mind, PEAR looks to become a 'standard way' for PHP authors to quickly do something. If you download a PHP script that uses PEAR, it wouldnt take someone familiar with the classes to go over the code and figure out what it does. On the other hand, this _does_ depend on PEAR actually being a sensible and well thought-out system, as if bad design creeps in, the lack of overlap either means breaking backward compatibility, or living with it. > This is important because each author can at least be morally compensated > for the effort of sharing their code for free. I lost the count of how > many authors have thanked me for having the site working that way. > Motivated authors contribute more than once for the joy of the PHP > community that access the site. The upload average is of 2 classes per > author. Hang on, it doesn't matter if the author uploads 10000 classes if they are all crap! Lets focus on quality here, not quantity. I have no doubts that your site has many excellent classes in there (although I wouldn't be sure how to find them - top downloads?), but even then, they would share no standard between them, apart from a single author's own conventions. The lack of standards is not a problem if I just want to download a quick class to do something, but I would hesitate to base a large project upon many differing classes. PEAR, however, does have this standard glue in the form of CODING_STANDARDS, and a large project (IMP 2.3 for example), gains a lot of functionality without sacrificing consistency and readability. > IMHO this is plain ridiculous. It sounds like the PEAR repository > maintainers would be doing you a favour to let you contribute with your > hard work that your are giving away for free!?!?! PEAR is just starting out - right now, too many cooks could well spoil the broth. Personally, I think it's in pretty good hands at the moment, from the classes I've seen going in (and, no, I don't have a CVS account) > I already said it and will say it again, the way I see it this is the > communist applied to the so called "Open" software development. Notice > that basically if you want to contribute you have to give your work away > for free, which is a fair rule), but only if the central committee (which > thinks is above all and everybody) approves it, which is an unfair rule and > that was precisely why communist regimes have fallen apart. This is completely bogus. If you feel that the PEAR project isn't what you want (as you are completely entitled to), then go ahead and fork your own project, and attract developers because you are doing it the 'right way'. There isn't a single successful open-source project that isn't 'communist', or 'despotic', since every project needs a clear, firm and consistent direction in order to succeed. If you feel the direction is not right, you can always take the code and do your own thing. It is a fair point that PEAR is a very closed development at the moment, and hard to contribute/maintain code to without CVS access to PHP itself. I presume that this will change as it matures, and possibly spins off into separate releases from PHP itself. Or does like CPAN and has different releases for each module. Whatever ... it's a growing entity and things will pan out. > This sounds like an invitation to leave. I am getting used to get this > kind of "stabs" once in a while from certain members of the PHP core > developers team just because they disagree from my point of view. You may > not realize just yet who you are hitting, but some day you will. Never > mind, I don't want to go where I am not wanted! :-( Come on, we don't need this bad feeling; all of us enjoy coding, we just aren't agreeing how - there's nothing personal in any of this :-) -- Anil Madhavapeddy, <anil@recoil.org>

« previous php.pear (#802) next »