alternative to the fopen() hack in autoloaders View as Markdown

Hi!

They dont want to determine if a file exists. They want to be able to
handle the case of a missing file being included differently than a
syntax error. Since php core does not provide such features, the only

Let's see why they need to handle missing file being included
differently? Or, even more interestingly - why they need to include file
that is missing if they know they'd have to do something different?
Maybe they would want to know if file exists or nor before trying to
include it, because they don't know which exactly file they are going to
include?
The goal here, at least for ZF, is to find the right file and include
it. Both APIs that I proposed allow to express it directly - find file
and include it. Your API would make them do it through chain of trial
and error by trying to include a string of non-existing files before
actually trying a successful one, thus mixing three functions - finding
files, including files and error reporting - into one. How it's better?

possible to do what the frameworks need with less overhead. There is no
way to do what these frameworks need inside userland without the above
mentioned hacks. The fact that almost all frameworks are forced to use

I just showed you at least two different ways to do it, with different
APIs. You may not agree it's right APIs but please don't make it appear
as your solution is only possible one in existence. It is not.

Now I also made it clear that its not about blindly silencing "errors"
but there is a need to differentiate between different error causes. Of

How you are going to differentiate? Your proposal only has one return
value (null) which is conveniently coincides with return value that can
be produced by include too by doing return;. You don't know why it
failed, you don't even really know did it fail or not. You just know you
got null in return.

1. checking before adds overhead and opens issue with potential race
   conditions

I don't think it's real use case - please show me one framework that
uses plugin includes through include path while other processes are
deleting their plugins randomly. I think you are trying to solve
non-existing problem here. Caching/templating APIs usually know exactly
where their files are and don't need to look for them in include path.

2. silencing the error and using track errors adds overhead and
   potential issues with custom error handlers

Again, what frameworks need is to find the right file among variety of
possibilities in include path and then include it. I think it can be
well served by using existing "include" with addition of "find" API and
there's no necessity for new language construct to serve one specific
use case. In a month, some framework would have slightly different use
case and you'd invent another packaged language construct for this?
There's a reason why language constructs tend to be primitive - because
you can assemble a lot of use cases from simple primitives, but it's
hard to deal with use-case-tailored constructs. We have four inclusion
constructs in language as it is, I think it's enough.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

Le Tue, 10 Nov 2009 21:56:47 +0100, Lukas Kahwe Smith a écrit :

ok .. so your objection to the RFC is solely because it introduces a
new language construct?

No, my objection is that it is not necessary to introduce a language
construct, and the construct introduced is not the right one. If
frameworks want to find out if file exists or get its name - we should
give them API to do that. If they want just to silence the errors -
they already have the construct to do that.

They dont want to determine if a file exists. They want to be able to
handle the case of a missing file being included differently than a
syntax error. Since php core does not provide such features, the only
way to do this is using the fopen() hack, iterating over the include
path .. or I guess track errors with @. My proposal actually makes it
possible to do what the frameworks need with less overhead. There is no
way to do what these frameworks need inside userland without the above
mentioned hacks. The fact that almost all frameworks are forced to use
these hacks and quite a significant number of developers use frameworks
(resulting in quite a number of apps end users install also using these
frameworks) implies that we are not talking about an edge case here.

Now I also made it clear that its not about blindly silencing "errors"
but there is a need to differentiate between different error causes. Of
course having to use @ for such a common use case is also not ideal. Its
just that the error handling we provide internally isnt really able to
handle this scenario well:

1. checking before adds overhead and opens issue with potential race
   conditions
2. silencing the error and using track errors adds overhead and
   potential issues with custom error handlers

Anyways, lets see if there are other comments in the coming days. I
think you have made your priorities clear. At least I understand them,
but do not share them.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

Hi,

I think if PHP throws exception instead of warning/error then this
problem will not have existence reason :

try
{
include 'file';

// if we are sure about data sort in get_included_files, just do :

$fullFileName = array_pop(get_included_files());

// ...

}
catch(phpParseIncludeException $e)
{
// ...
}
catch(missingIncludeException $e)
{
// ...
}
catch(includeException $e)
{
// ...
}

regards,
Alban Leroux
seza@paradoxal.org

Lukas Kahwe Smith wrote:

On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith

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.

ok.

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

Well I still maintain that is_includable() could imply for people that
no error can occur. Just like when calling is_int() means that it
really is an integer. so I still prefer "exists" or "resolve".

has syntax errors. A file with syntax errors is an exceptional
situation, and should be handled by a clear fatal error, imo.

well the error raised for a syntax error or missing file would not
change if we go in this direction.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

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.

ok. sounds like something that should be done.

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.

Well for all I care it could remain with stream_resolve_include_path(), though I am not sure if we really need that "stream" namespace, then again its a function that will not be used a lot in daily coding, so I do not care either way.

I have updated the current RFC accordingly:
http://wiki.php.net/rfc/autoload_include

So there are three approaches listed in the RFC:

1. http://wiki.php.net/rfc/autoload_include#proposal
   add a new alternative to include, which works the same except that for missing files it returns null and on success it returns the file location (unless the file already returns something else explicitly)

2. http://wiki.php.net/rfc/autoload_include#add_stream_support_to_includerequire
   add stream support to include/require

3. http://wiki.php.net/rfc/autoload_include#add_function_to_resolve_the_include_path
   fix up stream_resolve_include_path() to support streams.

I would like to call for a vote on the above. For 1) and 3) I invite everybody to optionally also submit a proposal for a name. Finally optionally include in your vote if would like to see this feature added to 5.3.2 or if it should wait for the next minor/major version update instead.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org