Re: Some more plane hacking...

Stig Sæther Bakken wrote: > > > I buy all your arguments about maintainability etc. But there are > some things that either _must_ be done in C (efficient asynchronous > IO, low-level database abstractions, GTK bindings or whatever) or that > would have significant performance benefits for everyone (the PEAR and > PEAR_Error classes will be used all over the place, why not save a > file parse?) I buy also your "speed improvements" ideas, but I'll try to give an idea about the problems with core C extensions. One day someone wake up with a new cool ultraRaiseError method and implemented it. Of course, Pear components starts to use it all arround. From this moment I must to stop upgrade all pear components I use in production envs, because I can not spend so much time compiling and testing. The life cycle of a php lib release is much more short than the one from a C extension. Other case: A user that have his pages hosted at an ISP and don't have the chance to upgrade C extensions (ini_* not avaible or no complier/knowledge). He have to wait until the next (normally still old) release of the extension shiped with the next release of PHP and is avaible in his ISP. Great problem here, as he must wait 4-5 months (if ever occurs) until he could benefit of the new features of for example Pear DB, while we are updating, enhancing, fixing Pear DB every day. Everybody could easily update a php component, not so a C extension. Make C extensions but maintain also its equal in php. Tomas V.V.Cox