Re: SPPLUS
| From: | Stig S. Bakken | Date: | Sun, 17 Nov 2002 02:04:32 +0000 |
| Subject: | Re: SPPLUS | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-10878@lists.php.net to get a copy of this message | ||
Replying a week late, but anyway...
This is a general comment (notice To:), related to this specific case
and to others.
Nothing in PEAR gets out to users without the knowledge of the
developers for each package. This means that it's _ALL RIGHT_ to have
ugly, buggy and non-CS-compliant code there for a while, as long as it
gets fixed before release.
Right now it seems that people expect stuff to be "1.0 release" quality
before even considering having it in PEAR/PECL. This gets all backwards
for me, CVS is a development tool after all. We can think like that for
the php4 CVS module, since everything there eventually becomes part of a
PHP release, but in PEAR everyone basically is his own master and has
full control over when the code is ready enough to be released.
Again, this is about package ownership, and not giving PEAR contributors
abuse before they have even had the chance to get accustomed to the
community.
- Stig
On Fri, 2002-11-08 at 15:31, Derick Rethans wrote:
> On Thu, 7 Nov 2002 nicos@php.net wrote:
>
> > Okay, here is the code:
> >
> > http://nicos.worldakt.com/spplus/
> >
> > files:
> > -config.m4
> > -CREDITS
> > -php_spplus.c
> > -php_spplus.h
> > -spplus.php
> > -tests/001.phpt
> >
> >
> > Just tell me if there are any bugs, I will patch.
>
> In the current state this code should definitely not be approved.
>
> 1. misuse of memory management (Strdupping return values and not freeing
> returned char*'s from the lib)
> 2. usage of tons of convert_to_String while using zend_parse_parameters
> would make the code:
> a. more readable
> b. much shorter
> 3. There is no test file per function, just one for all functions.
> 4. Comments as generated by ext_skel are not removed.
> 5. Messed up prototypes
> 6. Not complying with general coding standards
> 7. Unused, but defined MINIT and MSHUTDOWN sections
> 8. Missing licence header, including checks if the code is actually
> enabled
> 9. Function names in french
>
> -1 on this.
>
> Derick
>
> --
>
> ---------------------------------------------------------------------------
> Derick Rethans
> http://derickrethans.nl/
> JDI Media Solutions
> --------------[ if you hold a unix shell to your ear, do you hear the c? ]-
--