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

From: Date: Tue, 10 Jul 2007 11:44:39 +0000
Subject: Re: on the coding standards - Re: [PEAR-DEV] PEAR Group June 24 2007 Meeting Minutes
References: 1 2 3 4 5 6  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-47372@lists.php.net to get a copy of this message
On 10.07.2007, at 10:16, Alexey Borzov wrote:
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 reason is that if you use a byte code cache its way faster to read from there instead of having to do a file stat call to figure out the full path and compare it against the list if already included files. do note however that Rasmus uses freebsd, which supposedly is particularly slow for this operation. regards, Lukas

« previous php.pear.dev (#47372) next »