It's bothered me for quite some time that a failed include emits a
warning. This is because it's by design that the author chose
include and not require. It's expected that it may fail and they
are okay with that.
As an example, consider a classic autoloading case. It could be as
simple and performant as:
$file = /* something derived from class name */;
include $file;
But because of the warning, in practice authors tend to use
file_exists + require instead:
$file = /* something derived from class name */;
if (file_exists($file)) {
require $file;
}
Weird isn't it? Authors are using require instead of include for the
case where failure is tolerated. This is a clear signal to me that
include isn't doing its job. The warning gets in the way.
Any reasons we shouldn't just remove this warning for PHP 8?
Le 26 mars 2020 à 01:11, Levi Morrison via internals internals@lists.php.net a écrit :
It's bothered me for quite some time that a failed include emits a
warning. This is because it's by design that the author chose
includeand notrequire. It's expected that it may fail and they
are okay with that.As an example, consider a classic autoloading case. It could be as
simple and performant as:$file = /* something derived from class name */;
include $file;But because of the warning, in practice authors tend to use
file_exists+ require instead:$file = /* something derived from class name */;
if (file_exists($file)) {
require $file;
}Weird isn't it? Authors are using require instead of include for the
case where failure is tolerated. This is a clear signal to me that
include isn't doing its job. The warning gets in the way.Any reasons we shouldn't just remove this warning for PHP 8?
A quick look on the code base I’m taking care of, reveals that most include instructions expect that the file will be in fact included. If it isn’t, the error handler will be triggered and send me a bug report. (Yes I know, all those include could have been spelled require.)
On the other hand, in the occasional cases where I do want to include a file only if it exists, I wouldn’t lightheartedly remove the file_exists() check, because its presence makes the intent of the code clearer.
—Claude
On Thu, Mar 26, 2020 at 1:11 AM Levi Morrison via internals <
internals@lists.php.net> wrote:
It's bothered me for quite some time that a failed include emits a
warning. This is because it's by design that the author chose
includeand notrequire. It's expected that it may fail and they
are okay with that.As an example, consider a classic autoloading case. It could be as
simple and performant as:$file = /* something derived from class name */; include $file;But because of the warning, in practice authors tend to use
file_exists+ require instead:$file = /* something derived from class name */; if (file_exists($file)) { require $file; }Weird isn't it? Authors are using require instead of include for the
case where failure is tolerated. This is a clear signal to me that
include isn't doing its job. The warning gets in the way.Any reasons we shouldn't just remove this warning for PHP 8?
I don't think this really matches how include is being used in practice. I
think to the most part "include" is just the legacy spelling of "require",
and people are going to be very confused if it can silently do nothing.
If you want to make a change in this area, I'd go for deprecating "include"
to reduce the language complexity in this area (include, include_once,
require, require_once, which should I use in any particular situation?),
though probably the case for that is not particularly strong either.
Regards,
Nikita