Re: Re: cvs: php4 /pear Mail.php /pear/Mail rfc822.php

Chuck Hagenbuch wrote: > > Quoting Aaron Bush <abush@microcenter.com>: > > Is anyone working on documenting any of the modules, I started using the > > DB module and at times found myself wondering if i was using it in the > > 'correct/intended' way. > > Well, the list is here for questions. > This is true. I'll definitly use the list when i hit a snag. > > Should documentation be required before a new PEAR module is released > > with the standard PHP distribution? > > I think that it would be a good idea to require inline documentation. > I was thinking along the lines of at least a small portion of sample code to demonstrate how the classes can and should be used. I agree that inline documentation must be present before the source is released w/ PHP. > > I think that when a developer decides to use a PEAR module (is module > > the correct terminology to use; maybe classes?) they should not be > > bombarded with a mountain of interdependencies. It makes sense to reuse > > code between modules but I think that is should be closely watched so > > that we don't end up with huge classes when in the end the functionality > > achieved may be rather simple. PEAR should _help_ developers write > > efficient and maintable code not hurt them by creating large amounts of > > required source code in order to operate. > > Is there anything particular you have in mind here? Obviously we should avoid > dependencies if possible, but building larger pieces out of smaller components > is a great way to build up robust, complex applications. > > -chuck I think that the direction that has been taken so far with the Numbers/Conversion module expresses what i mean, through splitting a general idea of converting units into smaller sub-parts that the user can then pick and choose from. Basically, a user should be able to determine for themselves what modules they want to include/use and not end up with extra classes loaded thus bloating their environment. PEAR should be used as blocks in building your programs and the user/programmer should provide the glue to hold it all together with their own customized classes that extend if necessary. -ab