Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110067 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 3308 invoked from network); 7 May 2020 12:08:17 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 May 2020 12:08:17 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8D112180504 for ; Thu, 7 May 2020 03:43:39 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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-oo1-f44.google.com (mail-oo1-f44.google.com [209.85.161.44]) (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 03:43:39 -0700 (PDT) Received: by mail-oo1-f44.google.com with SMTP id p67so1204568ooa.11 for ; Thu, 07 May 2020 03:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fnc9ZRn0ZeLw8IJgb2gyyDamTyrbYdOVjjrWagrTVr4=; b=CepnHD5IKLkXRiux048Zp+3u6Q/rGo6mS/+ZRNNYxMdp1Zui+zEq8WMpL0Xzx67LeF CRD7KhxSOjxQlyT0W9lh/hudL3ZUQ7CERaEBFlF4fv+vLKTYrEX5Q88ixVQFiuFfJQri aXpc4GBgs+QLoona98Jfd+IGKTmc9wuIxB4imA78ueYaB+yH36X86JVmHx8aeydlif8U YcWcISJCUf3GgZ5SnyKXbSrYsxuDQ17K+VrVntH3UxOobmTdgKlEeYeKmVc5vd+ZmCsd MCzLOFGXbxVldH8HHPGSryAxEHozl7lIy+wlAqChDwjWEgr1KnaRD51d9ZSs8noHIANb CNMg== 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=Fnc9ZRn0ZeLw8IJgb2gyyDamTyrbYdOVjjrWagrTVr4=; b=KmWaWqO5gQZ7KW7PBYTEvTzAxflPy0OC7Bef+ug6GVtsyw8hFfvYhMF47dq6pgUK8S YYnBdTvTbrfblAJwQtuyfCIEIpg9gBndU1ygYtJ62ov1pOFgyaEJnUOlFwfbUTmPXJ55 fcM3SkzacklMIXi2RaOoGUXNXt1gE5Z/W3Pfol3A1h2HxtdUaT03oLeJ/Kddh6Lky+Dt QAacM2u55lgHIyAOAJ9XPOVtZTybdXb5iJ3R9bk118YgtO+dYI5EOO1SeiRSrMaWC4Kq fap/8MdSWWg84H++sP5Ro6lLoD6hC0rl5+BB9X4KfAKLqAIz0+iciyp2qRYFTPKoP0MO c9Qw== X-Gm-Message-State: AGi0PuZXy3BtStaSYa7YyIVgM1UHfNJd7qRUHpozi9iBrSFUw2iuOdWR +PrUYWRIFk2BQUeosqFayAnTnkVeNabNeexQPBtqcmJpssA= X-Google-Smtp-Source: APiQypIZlFjHe0Mk/gqAdog5eEEIV4DuWLYHqPb1LaY7H2BwvelmkTirr7BLIp+be8WgZ/IZczZBvuuA5WBtahcsL4I= X-Received: by 2002:a4a:da1a:: with SMTP id e26mr1030384oou.48.1588848217443; Thu, 07 May 2020 03:43:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 7 May 2020 12:43:25 +0200 Message-ID: To: Benjamin Eberlei Cc: PHP Internals Content-Type: multipart/alternative; boundary="0000000000009a51a205a50c8dd8" Subject: Re: [PHP-DEV] [RFC] <> Attribute From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --0000000000009a51a205a50c8dd8 Content-Type: text/plain; charset="UTF-8" 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. - all other languages with Attributes/Annotations support have it as well > Did you research what runtime side effects the other languages provide? 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. 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. 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. <>. 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: <> It could also be quiteuseful to have this trigger_deprecation() function in core, but that's another topic :) Cheers, Nicolas --0000000000009a51a205a50c8dd8--