Re: HTTP Class
| From: | Anil Madhavapeddy | 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>