Re: Re: alternative to the fopen() hack in autoloaders

Stanislav Malyshev wrote: > Hi! > >> A good point. Fortunately, most streams do store the filename in the >> stream struct, so this would still probably be possible in the majority >> of cases. If not available, the original requested filename is used >> (the one from the fopen call), so opcode caches probably could just use >> that. > > The problem is, by then the stream will already be opened, i.e. extra > filesystem call is done. Hi, Yes, but let's not forget we're talking about making this: <?php if ($fp = @fopen($file, 'r', true)) { fclose($fp); include $file; } // 2 stats, fopen + include ?> into this: <?php if ($fp = @fopen($file, 'r', true)) { include($fp); fclose($fp); } // 1 stat, fopen ?> Of course 1 stat is worse than no stats. Perhaps better would be to introduce a function: if (can_include($file)) { include $file; } opcode caches could easily snag this, as we could provide a simple hook the way we do with stream_resolve_path(). That would actually make a 0-stat smart autoloader a possibility. Just in case it isn't obvious, can_include() would be the equivalent to an include_path search followed by is_readable(), which is essentially what the fopen() hack does now. can_include() would also remove the unnecessary opening of the file that fopen() performs. Greg