Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117824 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 65501 invoked from network); 29 May 2022 13:51:32 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 May 2022 13:51:32 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 57EF21801FD for ; Sun, 29 May 2022 08:35:03 -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-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 29 May 2022 08:35:02 -0700 (PDT) Received: by mail-vk1-f177.google.com with SMTP id b81so3973363vkf.1 for ; Sun, 29 May 2022 08:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zn06Y8RT26iUUQG64UznFTaVz9Gv0N3nLnr/YDLWheo=; b=ya0dMxi8WRWRzjfpxqCG96xqKRYNpGsaDtKSDf3aqjJQsK8oqrLvRH1qQ89NyzDorb XnYH/EvuwZLvAS2M6UVwBlImOLp95RsmOZCRWoL4jFyqu1OkJJi5QQ7caiyu0ICBAiAZ mU4334OFVdAoGy29ATJ+qs+FpxyofKpu+CFm5BdieFMuT+uRaDKgpXZ51U+DmsdhN2ju dUxMUf1ZLkLBxjit/RMpHmm+qL6S7b8dGWeXJphpqMap51o/k30thATAJA5p0ltGVGO3 yVvQehg9l/oAQ88ztVbCgplpQpxO6U49664n7aBK4N5wAVN1DC2ar44U39ZHHJDKgPE/ ioEQ== 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; bh=Zn06Y8RT26iUUQG64UznFTaVz9Gv0N3nLnr/YDLWheo=; b=5qHkPsbpRHfRMRq9yqQItvKTe/jgg9E6u4rbH77iM2xEspMk7AqjmCg1GCXq1X6Opg 4racSlbO0Ky8h53bt2Fm/NhdXmV+umbPDFXIxP8nH1sOx2QIkNX67X1sJM48w1ftUGzB Y6NTyC5r6+BNWiSTQF8KD8dh3+2L8FeL7Q1F2Yvcrse/Tuw8stWNR3pqg3Er/8QSb+dO JaONslQfpeecE8Pzbvlhs0zDsSWdHl9ToZyFdrcR7HX63MszWTmP0uzqB0OfnevQtEs/ usJtDK/W8MJrQtdbP4x5LS70mcnNCj2mRlxGqm6WyIi0gwHXQN6k90yc0BzYfu13u06w 0kZw== X-Gm-Message-State: AOAM531W/R5jKymibsR7X7egJCrM5jfPjS2GqJafoI6Pv5YJQ15dLKK6 vJYAGj/yzjFVkasTCnOGEZ/endpXLdTkeyHD1GgS14LIdURZcw== X-Google-Smtp-Source: ABdhPJx3ISJA1odah62Piui7Tc5Ll1lJIqdhmRNWXq2SGRLY5RADCGELTnGQ57iqHh/Ed2yr2+Difg/Gy7nPRiH5rjA= X-Received: by 2002:a05:6122:2027:b0:35a:19c8:3ec7 with SMTP id l39-20020a056122202700b0035a19c83ec7mr5487496vkd.4.1653838501850; Sun, 29 May 2022 08:35:01 -0700 (PDT) MIME-Version: 1.0 References: <627D3BCF.7020903@adviesenzo.nl> <628F685B.8090909@adviesenzo.nl> <6291DBBC.8020403@adviesenzo.nl> In-Reply-To: <6291DBBC.8020403@adviesenzo.nl> Date: Sun, 29 May 2022 16:34:49 +0100 Message-ID: To: Juliette Reinders Folmer Cc: internals@lists.php.net Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables From: Danack@basereality.com (Dan Ackroyd) Hi Julie, On Sat, 28 May 2022 at 09:22, Juliette Reinders Folmer wrote: > > I admit, I puzzled over this for a little and wanted to take the time to respond properly before opening the vote, so I'm delaying the start of the vote until beginning of the upcoming week. Cool. Actually, I've just realised there is an error in the code in the RFC, which might be based on a misconception caused by how terrible callables are. In the code: if (is_callable('static::methodName')) { // For valid callbacks, this call will be executed in PHP 8.x, // but will no longer execute in PHP 9.x. static::methodName(); } The string based callable 'static::methodName' is not equivalent to the syntax* based callable static::methodName(). Using the string version consistently, the equivalent code would be: if (is_callable('static::methodName')) { call_user_func('static::methodName', []); } which for 8.2 gives the message 'Deprecated: Use of "static" in callables is deprecated in %s on line %d'. btw trying to call ('static::methodName')(); gives the error message 'Uncaught Error: Class "static" not found in %s:%d' which is part of the consistency cleanup done by the previous RFC. Using the syntax version, the equivalent code that would compatible with PHP < 8.1 if (is_callable(static::class . '::methodName')) { static::methodName(); } Or if support for less than PHP 8.1 can be dropped, using the first class callable syntax https://wiki.php.net/rfc/first_class_callable_syntax : if (is_callable(static::methodName(...))) { static::methodName(); } or $fn = static::methodName(...); if (is_callable($fn)) { $fn(); } Passing the callable round by getting the closure from static::methodName(...) is probably the safest way of referencing this type of callable. None of the syntax based ways of referring to the callable are deprecated or going to be removed in the foreseeable future. > for the practical implications of fixing the deprecations, > there is no difference between the two. People don't have to fix their code. Deprecations can sit there for as long as the user likes. If a company decides that paying RedHat for long term PHP 8.2 support, then they may choose to never fix these deprecation warning and just silence them instead. Which leads to a difference of, the deprecation notice when checking with is_callable and using the callable can be suppressed reasonably easily: @is_callable('static::methodName') @call_user_func('static::methodName', []); And that's a reasonably sane** thing to do. But the deprecation notice when passing callables around could happen across many pieces of code, and there's not a good way of suppressing them, unless you just turn off deprecation notices entirely. With the deprecation notice where a user is checking, and a deprecation notice where it is used, I don't see any value in extra deprecation notices where the callable is being passed around. > do you still feel that splitting the vote in two is the best way to go ? Yes, due to the deprecation notices on type-checks when calling functions have a higher pain-to-utility that in the is_callable check. Just guessing, I think the previous RFC thought a deprecation notice on is_callable isn't needed, as there will be a deprecation notice when the callable is used. But that probably didn't account for people being able to mix'n'match callable syntaxes, where is is_callable check, and the actual use of the callable, are not the same callable. I also like the deprecation notice on is_callable, as that notice will be 'closer' to where the bad callable is coming from, so would be easier to reason about. There's also a rare edge-cases where someone has a callable that is only called in emergencies (like a disk running out of space) and so might not have that happen for months. Having the deprecation on is_callable would help those edge-cases a little. cheers Dan Ack * Is "syntax based callable" the right name? Better suggestions welcome. ** compared to some stuff I've seen/written.