On Apr 9, 2012, at 6:22 PM, Tom Boutell <t...@punkave.com> wrote: > 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.
I don't cache the path and I wouldn't want to have to. My routes file simply has the controller class name. APC caches the path name and opcode. But I still have to choose _what_ goes in the require statement. I don't know about you, but my auto loader is extremely simple. Find the root namespace with strstr or strpos and check it in a registered namespace hash. A strtr to convert \ to /. Tack on a .php at the end and include. > >> 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 web server. Of course. Mine assumes, and always will, .php. I probably will keep <?php (just my personal preference) at the top but include classes in code mode. That way I'm free to include open source classes with or without the <?php. > 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. You aren't dictating best practices in an RFC. You're proposing an addition to the language. Best practices are discovered and agreed upon over time by the community. Separating HTML from code is already considered a best practice. The RFC assists in helping organizations enforce those practices (IF the choose to do so). >>> 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. Great! Then it seems we both agree. As far as the require/include statement, have we pretty much settled on something like this: include "/foo/bar.php", INC_CODE; verses: include_path "/foo/bar.php"; ??? Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
