Re: Re: cvs: php4 /pear DB.php /pear/DBcommon.phperror.phpmysql.php result.php warning.php

Chuck Hagenbuch wrote: > > Quoting Sebastian Bergmann <sb@sebastian-bergmann.de>: > > > Hm, I did this because I'm used to the concept of one class per file from > > - don't shoot me - Java. It sounds logical to me, but in the other hand > > your right, although I thought (and hoped) that performance issues related to > > multible disc accesses would be neglectable. > > I'm interested in other people's thoughts on this one - it certainly makes > sense to in general split classes out into new files. But some classes - like > PEAR:: and PEAR_Error:: - are core functionality as well as being closely > related, so it makes sense to keep them in the same file. > > I don't really know what the performance factors are; I imagine that modern > OS's disk caching should take care of most of it, but not at least thinking > about it and trying to reduce disk hits seems irresponsible to me. That's my reasoning as well, and the reason why it was the way it was. I believe we should free ourselves from the class<->file mapping though. It's possible to implement autoloading of both functions and classes in PHP, and this would make PEAR code more sane IMHO. If the PEAR installation tool (the one called "pear") maintains an autoload registry of functions/classes/macros and in which files they are defined, the compiler could "require_once" all the necessary files for you. No more "require_once" in PEAR or application code. - Stig