Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109317 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 57744 invoked from network); 26 Mar 2020 03:27:46 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 Mar 2020 03:27:46 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 518571804C6 for ; Wed, 25 Mar 2020 18:52:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 25 Mar 2020 18:52:31 -0700 (PDT) Received: by mail-wm1-f50.google.com with SMTP id b12so4892287wmj.3 for ; Wed, 25 Mar 2020 18:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5ZjehNatu6tMvGX5paRlGdeFZ+c/CQt+mLTu55KI2zw=; b=G3Q2jOHCyY//kgZ4xZHZJUcrOgTsFhPGY+e1N3RXmn+oceaascUjr3o5oSctOUiCWl v3IfLvRTgg1cSxevgEMhI97NO38tvwBA2W4w4q1TXaw4x3W+vMuLDnsqRW9u+s2cNS6C aV+gBJOdmctLVuSGTeHw2k1+7pMNkUM17SvjhhCt1LiieM4fjatZbbcznrWz/SNPiFqv CtsuBXPfBd+79S9U0//ct9keBj3jW40O4+v2EeJslo1Pe7o96vXlapiRDz/ROUa9JrwS gtdTgt5ELjeD/yl9H3DE535EcscxSng2JzvkLelOZPugnuGFGgREnao+kgBvCLmwMhic QgdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5ZjehNatu6tMvGX5paRlGdeFZ+c/CQt+mLTu55KI2zw=; b=lwkNwb5fDGHhynTRtGrlrvUdJSid6maVBWlj2Nmxmv7eyanAZf9Jcifx5/h6JpvJ9/ bIyj8JNyPJW8QizzG7LIKGYSIobcDPAuFAveO3gp+EadAcszubjpuFhkJhuHTzx2Mqpn /hdD2td4OhAjiYB6wrn8TLVHElZ6Yh+CTIQ7mPqzW91vEky2uY7rrrafDbTJQ7BTuepM ADw5q5r8O60hltjntfBWVPR03WZk9XXiYBHY8zSljge6KWeUcqTnlsluqEI+e+4CICAw Qm47VYFHzIV5YUnyXvNFQp7X/CmPkErir4z70zuKNnoyRJWtZDKatlOtp0F31VZxyxJn Abag== X-Gm-Message-State: ANhLgQ2n7V1ovXgCmLAhrtVlBFvk82Qx9DQRJMSlOodgNhu/IAPB4fGB bCx3pFew9xhlLot/kg5fIj8= X-Google-Smtp-Source: ADFU+vsUPoG6HgTVTfoGMd0EftbnHUkc0W1GLa7GU4AovF9uG5r8mAAQ5h2Tj12iyrHdbmg8o6sZtA== X-Received: by 2002:a1c:2056:: with SMTP id g83mr463493wmg.179.1585187549336; Wed, 25 Mar 2020 18:52:29 -0700 (PDT) Received: from [192.168.0.63] (84-75-30-51.dclient.hispeed.ch. [84.75.30.51]) by smtp.gmail.com with ESMTPSA id j5sm1275545wrr.47.2020.03.25.18.52.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 18:52:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) In-Reply-To: Date: Thu, 26 Mar 2020 02:52:27 +0100 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Levi Morrison X-Mailer: Apple Mail (2.3608.60.0.2.5) Subject: Re: [PHP-DEV] Removing warning for failed include From: claude.pache@gmail.com (Claude Pache) > Le 26 mars 2020 =C3=A0 01:11, Levi Morrison via internals = a =C3=A9crit : >=20 > 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. >=20 > As an example, consider a classic autoloading case. It could be as > simple and performant as: >=20 > $file =3D /* something derived from class name */; > include $file; >=20 > But because of the warning, in practice authors tend to use > `file_exists` + require instead: >=20 > $file =3D /* something derived from class name */; > if (file_exists($file)) { > require $file; > } >=20 > 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. >=20 > Any reasons we shouldn't just remove this warning for PHP 8? >=20 A quick look on the code base I=E2=80=99m taking care of, reveals that = most `include` instructions expect that the file will be in fact = included. If it isn=E2=80=99t, 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=E2=80=99t lightheartedly remove the = `file_exists()` check, because its presence makes the intent of the code = clearer. =E2=80=94Claude=