On Mon, Apr 9, 2012 at 9:11 PM, Luke Scott <l...@cywh.com> wrote: > Given that an autoloader just has the class name with the attached > namespace, how is it to know whether or not to load a .php file or a .phpc > file? I'm not going to add a stat in my autoloader (file_exists) just to > check for the existence of one or the other. > > With APC I'm able to do apc.stat = 0. The stat happens once per file > before the opcode is cached. After that no stats happen. Adding a > file_exists bypasses this.
This does not change. If you have cached the location of the .php file, you can just as easily cache the location of the .phpc file. You don't have to do a second stat either if your convention for that library is that everything is .phpc. But even if you did do two stats, it's only on the first pass - as long as you adopt the convention that .phpc wins when present. No need to get crazy and look for otherwise identically named .php and .phpc files and worry about which is newer (: This is even more simply avoided by choosing a consistent convention for a library of classes and not even looking for the other type for that library. > Now as others have said: File extension is irrelevant. It's up to the web > server to determine this. > Not entirely sure everyone wants another extension though. Such things > shouldn't be in the RFC since it's a web server thing anyway. First, it is not true that file extensions are irrelevant to the actual PHP code. Every autoloader makes a file extension assumption and gets no help from the webserver. Second, proposing best practices to the community in an RFC makes sense if they contribute to its successful adoption. There are, I guess, environments in which extensions don't matter, but in most of the real world, extensions do matter, and where they do matter, consistency is helpful (: Thus a convention is proposed but not enforced by the RFC. When things are worded this way we don't get tripped up by the existence of edge cases where the convention can be safely ignored. >>That said, allowing the skipping of an initial <?php tag at the top of >>the file probably wouldn't be a big deal to implement in code mode. > > > OK. If you can agree to this then I'm good. Perhaps only allow white space > before it (which is ignored - everything else throws a parse error)? Great, that sounds doable. (This would be *allowing* a leading <?php, not *requiring* one.) -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
