On Wed, 5 Dec 2001, Daniel Lorch wrote:
> It's nice having an out-of-the-box solution - everything just works > fine, just load the module (i.e. uncomment # in php.ini). Nevertheless, > who actually decides how a module's interface is designed? I know, > there are some guidelines, but this still ressembles too much to > anarchy in my eyes. What belongs into PEAR and what has to be done as > module? IMHO, a programming language gives the user essential basic > abilities, such as creating sockets, file system access, of course > providing a syntax, memory mangement etc.. and then it's up to the > PHP developer to create additional modules. This will provide better > transparency to the end-developer as he will be able to look at the > PEAR-sourcecodes and actually /understand/ what is being done. Why > does every PHP developer has to know C only to understand how such > modules work? > > Too many modules were developed lately. Why not add a daniel-module > which only serves my needs, but goes into the main CVS tree? > > Correct me, if I'm wrong. Your opinions please :) > Sure, create your little daniel-module. If it isn't very important it will probably go into PEAR / PECL. What's the big deal here ? Joao -- João Prado Maia <[EMAIL PROTECTED]> http://phpbrasil.com - php com um jeitinho brasileiro -- Precisando de consultoria em desenvolvimento para a Internet ? Impleo.net - http://impleo.net/?lang=br -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
