Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110075 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 33352 invoked from network); 7 May 2020 23:34:58 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 May 2020 23:34:58 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 29F1C1804C4 for ; Thu, 7 May 2020 15:10:30 -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,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE 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-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 ; Thu, 7 May 2020 15:10:29 -0700 (PDT) Received: by mail-wr1-f42.google.com with SMTP id l18so8275005wrn.6 for ; Thu, 07 May 2020 15:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beberlei-de.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=30swPZqULWiwxy60vFQH2BNGegeadSJvI+GYRtcTTS0=; b=B2jjfpU9ikhvDC9MUemrAvIan+RjAvOvpNJMhpVLBKXuj1x8Oo9owZpuxMRpVAizVU GwxOsSUkPB1lLnqUmWrzR7c+fXAneHVKGHQ4dmh7odgCoxDEQHsNMZ99Ppsd0aBf0wxV IHCoYrfcoVixBzTontB/pTsnD49FzM6HoLb9nIyx5ywPe6+2eAc3gaxG3h9GQjJ6azwo lTeTRwcudNURV9Vp0feVwAvKVD0HDUX3FDl4ySXWBZnwHTqityGNeqJnFc9Bwy9l0yrR 6GcTt1Z1i31rzX8b9KL9CPon3f2ejuK4p9oEpgNgOhpoVJqf5r8rGHFqg+7tA+xlseeL +QmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=30swPZqULWiwxy60vFQH2BNGegeadSJvI+GYRtcTTS0=; b=S77t3aPP31gP9KbGajeMp12FQ+O0WAIwlgw8C7PJAMLnyvTzWaPu2/oFUvNj9YgvKR 2L7HiWj1vtEz5pEJNxq4EyWI09RxcUfXINbXeFrXfTqstg6hX1i4zKOFeR1JNdRisFcQ m3NVmPj3BXsp3dggyhN3Wahq1MI6J5HeQIuheASt6m9BaEln3iB6IA+5ImzAjO3yVLzt DAabZqimNzpUCZ7ULS7uRKcK9SrdmSJFScqPhX2koeaQ/qSLvdfLv8eU2tvoxqzrMvRj /SSqikdkFgkhlnXIdT3RHrtHUptgOBtZGgvN6D8sg+gI+BPpUKsrOqBvQEGh2hpBkcUq N6sw== X-Gm-Message-State: AGi0PuYz4CSQRYZCjRq6n5u0kmnlhGh2d5vJjtG47CXzmLl7vPdNWfgK JdDvdVOOLgOBwbG0V9QdV/+wO9ca/qDNruEwJfai9A== X-Google-Smtp-Source: APiQypLaWMhJSwJo80Oa20n35bPR/5FHec1ztJCOFZS2QvoyAadPkZ/wn9TEo6lmaWs0PuPwa1+SLBmEKvp7M5tGspE= X-Received: by 2002:a5d:5608:: with SMTP id l8mr1586641wrv.16.1588889424916; Thu, 07 May 2020 15:10:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 8 May 2020 00:10:13 +0200 Message-ID: To: Nicolas Grekas Cc: PHP Internals Content-Type: multipart/alternative; boundary="000000000000c28a2405a516255d" Subject: Re: [PHP-DEV] [RFC] <> Attribute From: kontakt@beberlei.de (Benjamin Eberlei) --000000000000c28a2405a516255d Content-Type: text/plain; charset="UTF-8" On Thu, May 7, 2020 at 12:43 PM Nicolas Grekas wrote: > Hi Benjamin, > > https://wiki.php.net/rfc/deprecated_attribute > > > Thanks for the RFC. > Why didn't you mention support for deprecating classes/interfaces/traits > themselves? > If there is a reason, it should be in the RFC at least to me. > It feels complicated to me, because there are so many entry points to a class: 0. declaring/loading it 1. extending it, but not always because the replacement could extend it 2. calling it statically 3. instantiating it 4. i probably forget a bunch. I think this requires spreading the code to handle this around into many places and is not easy to do without overhead for classes that are *not* themselves deprecated. So I decided to keep this out for now. > - all other languages with Attributes/Annotations support have it as well >> > > Did you research what runtime side effects the other languages provide? > They mostly warn or fail on compile and don't have runtime effects. The same goes for any other deprecation that PHP triggers though, they are all at runtime. So I don't think this can be compared, similar to how the error stack of PHP cannot be compared to any other language. > > I'm concerned about runtime side-effects. Attributes should lead to none > of them to me. The moment an attribute leads to runtime side effects, it > should be turned into code instead, because it looses its "declarative" > property. > To me Symfony using Annotations at the moment is also all about side effects based on declared annotations that are then automatically turned into code. This is the same happening here. The difference to this example here https://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/security.html#usage is only that <> will generate the code into the function/method, whereas the annotations in the Symfony example generate the code "around" (before) the method call. > > From my experience, e.g. a method can be declared as deprecated but can > *still* be called internally without any issue. This should not be reported > to anyone as its internal. Preserving BC often requires this, and only > runtime logic can decide when a deprecation should be reported to the > end-user. Note that this is different from configuring the global error > reporting level: deciding *locally* that some declaration should not be > reported is the important part of this. > Can I ask how you are handling this use-case in Symfony at the moment? If you catch that in the error handler by looking at the backtrace, then this is exactly possible with this declarative approach as well, in fact the generated code is just calling trigger_error() and then triggering user error handlers. > > That's also why I very much favor @trigger_error() and why static analysis > works only for the simpler cases. > > If one wants to save the duplicate "declaration" (attribute + explicit > call inline), then this should be opt-in to me, e.g. <>. > If you only want the static analysis effect, developers are still free to use /** @deprecated */ instead, which I don't expect either static analysis tools nor IDEs will drop support for. > > As an additional step, I very much which that the attribute could accept > two arguments: the package and the version of it. From my experience, > making deprecations actionable is critical to help ppl to fix them. And > making them actionable starts with allowing ppl to quickly identify which > package cannot be upgraded to the next major yet. > > This is what make us work on symfony/deprecation-contracts > , which provide this > single trigger_deprecation(string $package, string $version, string $ > message, ...$args); function. From the example in the readme: > > trigger_deprecation('symfony/blockchain', '8.9', 'Using "%s" is deprecated, use "%s" instead.', 'bitcoin', 'fabcoin'); > > Generates: > Since symfony/blockchain 8.9: Using "bitcoin" is deprecated, use "fabcoin" instead. > > Joke aside, this is very useful and I wish the attribute could borrow from the experience we gathered on the topic. > > This would be nice: > <> > > The Deprecated attribute accepts a message that gets appended to the default message, so you could do <>, which would turn the message into: Deprecated: Function bitcoin() is deprecated, since symfony/blockchain 8.9, use fabcoin() instead in /path/to/file:123 A free-form text is more flexible for use-cases where there are no package and versions, we can't expect to assume every deprecation will be triggered from a versioned composer package only. > > It could also be quiteuseful to have this trigger_deprecation() function in core, but that's another topic :) > > Yes, a declarative statement like <> would have the benefit of keeping the implementation hidden, so details of it could potentially be changed. > > Cheers, > > Nicolas > > --000000000000c28a2405a516255d--