Re: on the coding standards - Re: [PEAR-DEV] PEAR Group June 24 2007 Meeting Minutes

----- Message from borz_off@cs.msu.su ---------

Hi, Adam Ashley wrote:

"*_once including of files not allowed" - Requires autoload() mechanisms, which are not considered by all to be the best mechanism for loading files and documenting code.. - This is a significant change and would need serious backing by all members.. I think a long time ago someone proposed class_exists(.....) ? false : require_once '......'; This seems a better compromise - as it solves 2 problem with one shot. - although an import statement would be better......

The issue trying to be solved here is to be opcoce cache friendly.

I'd really like to see something like "developer X, who maintains opcode cache Y, suggests this approach in his (tutorial|presentation|article) which can be read at [Z]." here, not just vigorous handwaving.

I mentioned this in my first email but to spell it out: Rasmus Lerdorf's LCA2007 PHP presentation 'Better Web Apps with PHP 5' slide 11 contains the numbers you want. http://talks.php.net/show/lca07/11 Or any of his presentations for the last year, I use the LCA2007 one simply because I was there

Yeah, I've heard a variant of this, too, when Rasmus was in Moscow in 2006. But I still don't see "having a file with 10 'require's, most of which are not needed, is better than having a couple of 'require_once's in strategic places". Especially since later Rasmus talks about eliminating useless 'require's.

The allfiles.php isn't for those after performance. It's for those that want the simplicity of include one file to get everything in the package and it just works. allfiles.php is intended to duplicate the current behaviour while not impeding those that need to get every request per second they can. Lukas' last email said it best I think:

1) The idea is to provide an optimized solution for multiple "audiences": - speed freaks - unzip and go types - maintenance flexibility freaks

I am 100% a speed freak for my main use of PEAR packages, if I had more hours in the day I would be maintaining a duplicate PEAR without all the conditional includes and *_once calls, but I don't. So I am really very very happy seeing new PEAR standards requiring supporting all these cases not just the one the developer of the package happened to be in tune with when he first designed it. Adam Ashley