Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46027 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 18809 invoked from network); 11 Nov 2009 13:50:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Nov 2009 13:50:46 -0000 Authentication-Results: pb1.pair.com header.from=greg@chiaraquartet.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=greg@chiaraquartet.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 72.14.220.154 cause and error) X-PHP-List-Original-Sender: greg@chiaraquartet.net X-Host-Fingerprint: 72.14.220.154 fg-out-1718.google.com Received: from [72.14.220.154] ([72.14.220.154:54581] helo=fg-out-1718.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4A/19-65174-431CAFA4 for ; Wed, 11 Nov 2009 08:50:46 -0500 Received: by fg-out-1718.google.com with SMTP id d23so400380fga.11 for ; Wed, 11 Nov 2009 05:50:41 -0800 (PST) Received: by 10.86.203.35 with SMTP id a35mr1140669fgg.44.1257947441131; Wed, 11 Nov 2009 05:50:41 -0800 (PST) Received: from monster.local ([76.84.35.200]) by mx.google.com with ESMTPS id e20sm4612225fga.15.2009.11.11.05.50.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Nov 2009 05:50:39 -0800 (PST) Message-ID: <4AFAC12B.7000909@chiaraquartet.net> Date: Wed, 11 Nov 2009 07:50:35 -0600 User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807) MIME-Version: 1.0 To: Lukas Kahwe Smith CC: Mikko Koppanen , Stanislav Malyshev , internals@lists.php.net, Christian Schneider References: <413588E2-8AC8-49F7-B7BF-97BEFB0A71E4@pooteeweet.org> <4AF9A03E.8000207@cschneid.com> <4AF9AE1A.9000005@zend.com> <4AF9C589.3090604@chiaraquartet.net> <4AF9CCEA.1030500@zend.com> <4AFA0449.2030600@chiaraquartet.net> <4AFA0756.4020609@zend.com> <4AFA0A38.7000502@chiaraquartet.net> <8B520687-04D6-4CB3-BB7A-51A62D74489B@pooteeweet.org> <8cf711460911110244m22e2fedag21e294d8d3909037@mail.gmail.com> <65D94139-8A66-4C89-8418-160F5B2A4280@pooteeweet.org> In-Reply-To: <65D94139-8A66-4C89-8418-160F5B2A4280@pooteeweet.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: alternative to the fopen() hack in autoloaders From: greg@chiaraquartet.net (Greg Beaver) Lukas Kahwe Smith wrote: > > On 11.11.2009, at 11:44, Mikko Koppanen wrote: > >> On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith >> wrote: >>> >>> On 11.11.2009, at 01:50, Greg Beaver wrote: >>> >>>> if (can_include($file)) { >>>> include $file; >>>> } >>> >>> >>> I am sure you focused on the technical aspects. Just wanted to say >>> that for >>> a name "can" is not ideal, because there is no gurantee that the >>> file will >>> not have syntax errors. As such something with "exists" is better (for >>> example include_file_exists(), though also not ideal) .. Stas >>> proposal of a >>> "file_find()" is also good, but I think it would be nice to have >>> "include" >>> in the name. >>> >> >> Isn't this what stream_resolve_include_path does? > > it might .. the doc's are sort of unclear .. since fopen optionally > checks the include path. then again the name of the function implies > that it does a search in the include path. the name is a bit long .. > but i like the use of "resolve". > > so a byte code cache should cache the resolution of the path thereby > speeding up the subsequent call to include? stream_resolve_include_path() as currently constructed could not be intercepted, and is actually unable to process an include_path that contains streams. I'm guessing it was written long before PHP 5.3. This could be easily fixed by having stream_resolve_include_path call zend_resolve_path() instead of doing its own internal calculations. With these changes, an opcode cache could easily cache the results. As for your naming concerns, if we were to add an alias called is_includable() to stream_resolve_include_path(), that would be much clearer: if (is_includable($file)) { include $file; } The assumption here is that we are simply testing whether the file exists and whether php can actually read the file, not whether the file has syntax errors. A file with syntax errors is an exceptional situation, and should be handled by a clear fatal error, imo. Greg