Re: PHPlib PEAR

From: Date: Fri, 19 Jan 2001 20:13:20 +0000
Subject: Re: PHPlib PEAR
References: 1  Groups: php.pear 
Request: Send a blank email to php-pear+get-1072@lists.php.net to get a copy of this message
A nice imagination would be, that in the PHPLIB container is something like an application framework, wich uses standalone PEAR components and gives you a base for web applications. Of course, you can combine the standalone components by yourself but PHPLIB could be a platform for big PEAR based applications where many developers are involved. The lib´s "spirit" AND functionality would reside in PEAR.
some storm out of my brain: I) answer (see above) II) PEAR policies and CPAN I) what I had in mind is similar a) PHPLIB split up and merged into PEAR and partially vice-versa (db classes will improve for example) b) PHPLIB residing somehow in an /application dircetory as a TEMPLATE for generating PHPLIB things (I have to say things, because I never used PHPLIB, just had a few looks) THIS (b) is a major point! Why? There will be "examples" how to use PEAR classes in combination to solve various problems, examples are great for anyone to be able to (i) figure out it these components are the right ones to choose for certain prooblems (ii) understand how single classes and how they work in conjunction with other classes c) /PEAR will be filled with many classes d) /PEAR/applications will grow with example/template-like applications demonstrating their usage II) regarding POLICIES or "avoiding the CPAN thing" a) 1.) how do we avoid that _anything_ will be added into PEAR, authors willing to contribute should at least send a discussion-request to the list, eg. I would not be happy seeing a class "add_two_integers" in PEAR, would you? 2.) it does not matter to have 5 classes beeing able to create HTML out of variables and templates and the like, but not everyting should be accepted, but I am not really sure what _should_ be accepted and which reasons will should lead to rejection at least people should spend some time with their code, to avoid putting legacy code into PEAR without active development, without PEAR conformance, just to have it in b) forcing developers is bad missing documentaion is bad good documentation is hard to write and to maintain I would like to _strongly_suggest_ to PEAR developers to add examples demonstrating all functionality in a very simple manner with _basic_ documentation like two or three words regarding intended use, I would send this to /PEAR/applications/examples, whatever examples are the best point to roughly start understanding, messing and using classes I think An important part will be to let outsiders know if development is active or not and even better (but hardly to realize), if people are using it. eg. version history with dates, last maintained/improved dates andré -- · André Langhorst · t: +49 571 3201801 · · waldschrott@php.net · m: +49 173 9558736 · · PHP Quality Assurance · http://qa.php.net ·

« previous php.pear (#1072) next »