RE: [PHP-PEAR] PHPlib PEAR

Concerning Point 2, below, "it does not matter to have 5 classes beeing able to create HTML out of variables and templates and the like, but not everything should be accepted" I wish to emphasize this point from a typical developer (library user) perspective. When looking for some functions/classes with file management abstraction, I would typically visit hotscripts.com or freshmeat.net, phpbuilder.com, etc, to avoid reinventing the wheel. However, having to wade through and evaluate 15 different implementations of almost identical functionality defeats the purpose. I often end up creating my own library, not because I can make a better wheel, but just b/c there are too many wheels to choose from. So, from a typical PHP developer's perspective, I would like to see PEAR as a repository where I can find only the best code. --Confident that any PEAR class I use will have been strictly evaluated at some point, and accepted because it adds value to the community. If this is the direction that PEAR is heading already, then good. If this is the case, what are the criteria for submitting code to PEAR? Or is it too early to say? How do other OO languages (Python?) differentiate between core classes, extraneous classes, and application frameworks. My 2 cents. -Ben Munoz -----Original Message----- From: Alex Black [mailto:enigma@turingstudio.com] Sent: Friday, January 19, 2001 12:40 PM To: php-pear@lists.php.net Subject: Re: [PHP-PEAR] PHPlib PEAR > c) /PEAR will be filled with many classes > d) /PEAR/applications will grow with example/template-like applications > demonstrating their usage do you mean little bits of sample code that use the classes? > 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? I agree, but that must be handled delicately. For additions to binarycloud, I intend to set up a community approval system, so there is not some "council" that tells you if your code is ok or not. > 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 above. > 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 I agree with that. > b) > forcing developers is bad > missing documentaion is bad > good documentation is hard to write and to maintain yep :) > 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 that sounds cool to me. > 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 all of these tools are going to be developed for binarycloud.com thus my earlier suggestion to use binarycloud to co-develop some tools that both binarycloud.com and pear.php.net will need. _alex -- PHP Extension and Add-on Repository (PEAR) mailing list. Documentation can be found at http://pear.php.net/doc/pear.html To unsubscribe, e-mail: php-pear-unsubscribe@lists.php.net from the mail address you subscribed with.