Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117545 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 96992 invoked from network); 19 Apr 2022 16:47:02 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 Apr 2022 16:47:02 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DF457180539 for ; Tue, 19 Apr 2022 11:20:34 -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=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE 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-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (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 ; Tue, 19 Apr 2022 11:20:34 -0700 (PDT) Received: by mail-lj1-f181.google.com with SMTP id h11so21575018ljb.2 for ; Tue, 19 Apr 2022 11:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dqxtech-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mbCyfe88yp7Z2bT5vsgge6QHwwBWWrRGz/+LRmGx9dI=; b=YnJ+jLkbmbSKps1Cd3VOHDTe8Y6RgV4HN7I9MbH46TkiPtJU1KQ/1H2n+3V010xlu5 oLPvIfjY2P/wC6r02mLAfE8+HH+hhjUYcaDvPmL5wNN/Xr6KjB7EnYLLdkiTBpyyzLWf mb9qTk3wKH0QW8dbcomJG1ES92ONZ57aiJsWVWR2QfFcwwqHufPnzUnWhNbK4alNr0Bq wDnGWsnKqojoRDH2D7hTEgMGTRILr7QXU5HTNOBNGiXomQKEUp3gBsEalivdfPmlASxl 0JA2pxcDyHLXbaPwMi+7xIQzGYJAd9Vnm7Lfv47tCM0HVlnQUGJWEfYEOTVZ0yOE5Zve uzkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mbCyfe88yp7Z2bT5vsgge6QHwwBWWrRGz/+LRmGx9dI=; b=tR/b30PWDfJzPVn4Pm54LM+T20Mh8P8kUrarInmkoaojD4mf3asiMJZTvZoM8iedh2 VNi4T+CXBVjPpY8m1aPLvKjqE8PeL9Q+tRq4KFQf0HvkxrUnL59LTN5cF5mEZexZW+6E mn9rfoTyC0aseTf1QzovmwfnZPOdDiA2MPGzyLxEyN0X9TJxvQPdLvuNQOz8Q7f4wVo1 U84C2X8EJQBDWJBl+af+zA9pv0HlL1nnq+gWT+aTbHvR236YnNieIOdrUYc3d8m3uPjs sfbHTkQAqMKTNz51ExXLh1zQA/TRW6I1FisAEWsAMG6tq3XNB5tGqKdBICxdSF91OsY+ kDMg== X-Gm-Message-State: AOAM532y79FRV197rAltarO7TrHsbJIEMxRAl/rWSPzNcJunJYfXlxHH QkXSXzth23bqvpQlCupD7E1fXZmcpXxtkvBAMkYGfg== X-Google-Smtp-Source: ABdhPJwhNadPb62G8/WXXMxDGM8cz+D8VO1X0c8Y/XTvubmlUcgNOCxA9/pNrT8+PteS2fex2UyXmIody4XP0QVoNCw= X-Received: by 2002:a05:651c:19a4:b0:24d:c2bd:ca9d with SMTP id bx36-20020a05651c19a400b0024dc2bdca9dmr4859869ljb.465.1650392432495; Tue, 19 Apr 2022 11:20:32 -0700 (PDT) MIME-Version: 1.0 References: <62317B01.90907@adviesenzo.nl> <70c5d418-7472-7f87-dc2c-e1a60ee09df6@gmx.de> <6234BB7F.90507@adviesenzo.nl> <0E683978-1E7F-4033-8B6D-F0CB74CC214C@gmail.com> In-Reply-To: <0E683978-1E7F-4033-8B6D-F0CB74CC214C@gmail.com> Date: Tue, 19 Apr 2022 20:20:21 +0200 Message-ID: To: Claude Pache Cc: Juliette Reinders Folmer , "Christoph M. Becker" , PHP internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throwa deprecation notice ? From: andreas@dqxtech.net (Andreas Hennings) A deprecation warning on is_callable() would imply that in a future version of PHP that call will be illegal. But this is not the case. is_callable() is meant to accept any value, and return true or false. is_callable('static::method') will still be a valid call in future versions, only the result will be different. This change simply cannot be covered with a deprecation warning. Developers have to update their code when they upgrade to PHP 9.x, or they need a PHP_VERSION_ID check, as sad as that is. One solution could be to accept an additional parameter to enable the forward behavior for is_callable(). But then this parameter would have to be removed again later. Also, is_callable() already has two extra parameters, so it would get crowd= ed. -- Andreas On Tue, 19 Apr 2022 at 17:18, Claude Pache wrote: > > > > > Le 18 mars 2022 =C3=A0 18:03, Juliette Reinders Folmer a =C3=A9crit : > > > > On 18-3-2022 14:37, Christoph M. Becker wrote: > >> On 16.03.2022 at 06:52, Juliette Reinders Folmer wrote: > >>> I've just been looking in detail at the Partially Supported Callables > >>> deprecation RFC: > >>> https://wiki.php.net/rfc/deprecate_partially_supported_callables > >>> The RFC explicitly excludes the `is_callable()` function and the > >>> `callable` type from throwing deprecation notices. > >>>> The |is_callable()| function and |callable| type remain side-effect > >>>> free and do not throw a deprecation warning. They will continue to > >>>> accept these callables until support is removed entirely. > >>> While I can fully support this for the `callable` type, I wonder if t= he > >>> decision to not throw a deprecation on use in `is_callable()` is the > >>> right one (though I understand the desire to keep it side-effect free= ). > >>> Consider these code samples: > >>> function foo(callable $callback) {} > >>> foo('static::method'); > >>> This function call not throwing a deprecation is not problematic as i= n > >>> PHP 9.0 the function will start throwing a TypeError. > >>> if (is_callable('static::method')) { > >>> static::method(); > >>> } > >>> The second code sample, however, is problematic, as in PHP 9.0, the > >>> behaviour of this code will be silently reversed for those callbacks > >>> which would previously result in `is_callable()` returning true, whic= h > >>> makes this a potentially dangerous change without deprecation notice. > >>> Would anyone care to enlighten me as to whether this was given due > >>> consideration ? > >> Frankly, I don't know. Apparently, there was almost no discussion abo= ut > >> that RFC. Part of the reasoning to not raise E_DEPRECATED when callin= g > >> is_callable() was likely the typical use case > >> $callable =3D =E2=80=A6; > >> if (is_callable($callable)) { > >> call_user_func($callable); > >> } > >> what would report the deprecation when actually calling the callable. > >> Not sure what to do regarding your given use case(s). > >> -- > >> Christoph M. Becker > > > > Unfortunately, those aren't the only places I see this happening and my= example is not a stand-alone case either. > > > > I came across the above code sample ( is_callable('static::method') / i= s_callable(['parent', __FUNCTION__]) with variable method calls) in a numbe= r of different packages when testing a (PHPCompatibility) sniff I am writin= g to detect the deprecation, so this code pattern looks to be relatively co= mmon. > > > > Some examples: > > * https://github.com/symfony/service-contracts/blob/bc0a2247c72d29241b5= a06fb60dc1c9d9acf2a3a/ServiceSubscriberTrait.php#L39 > > * https://github.com/mockery/mockery/blob/c10a5f6e06fc2470ab1822fa13fa2= a7380f8fbac/library/Mockery/Mock.php#L960 > > * https://github.com/simplepie/simplepie/blob/dacf0ed495d2e8fb306e526ca= 3f2a846af78a7c9/tests/oldtests/absolutize/RFC3986.5.4/base.php#L13 > > > > As I think that it is a serious oversight of the RFC, I have open: > > https://github.com/php/php-src/issues/8401 > > =E2=80=94Claude > >