Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110059 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 74161 invoked from network); 7 May 2020 10:07:17 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 May 2020 10:07:17 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 60D911804FD for ; Thu, 7 May 2020 01:42:40 -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-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 01:42:39 -0700 (PDT) Received: by mail-wr1-f54.google.com with SMTP id w7so4472078wre.13 for ; Thu, 07 May 2020 01:42:39 -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=fKQizS3JzpuVD8UKE2Zv9hgDVrVAYVHhbZu105yhQ1A=; b=m2gANNLx7VF+0JEArzLxvH2j+84O/kSONICdDf5mbMpaCEYtfRDW7chrsDSLZGvvtb ndcFguIcc5P26+t8sSMvzZpdSu6AHvEm27bsZpgSrpse70wJAxuZ7U4S3c4zu1dQCLfr erPliXSMI2SQ6+QinTVs0FpVqgs7MX75Eu8NBXbfo8k9+vJKyHWtN15Fpt1WXRX5RHPk zE4c0TGKgQKi9wI+yw1XyOCPtZiK0OEnjfMBMysJmSDNg2QuA+zbASQdY7wWdjIYf6s4 E5SWjbvHAkwisAW2BF7aa9gV5ZteYphcGVBv1DJaAs6wm5dauTU8w3G7X7G4/7JrhkPC 1UiQ== 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=fKQizS3JzpuVD8UKE2Zv9hgDVrVAYVHhbZu105yhQ1A=; b=Xb8b7ZpDA1YTlso5Wcwy0tvuN9PiXtBpoN2P88gmHf17oEzoL3moMT63L6AYEXZpp9 q9v462URzOJ8bo+GPR6UxNhGbWY8MNV80LST/nadH12d6zSgj11etqeiGVUTHnjewiLA Wv11A7SO7Oh15hmcCk3KJB4IVlqUlKXysSiHlOrEjGx7Axr8MJVwFk98URIFaPw34ZTX Tn6Vx2Tw8UMw+EJP9l8J+WiMGRa548I9fFRpokl7ULiOp71HkhVUJmnr8HKYtv+DDT+u 3F4kDpc0f4iOHELM0ONwg2tOZpIh/mjYUSClH5VSswrGlZdOWBwo7qoF9yc8EAzttJ+F dbmA== X-Gm-Message-State: AGi0PuZAYuS3Tu/+UdMM4mId94ERT2EGm8/ODZEWg3d10y0ZyUk8rLuo hgL7G/TZjAbUSxFcIeCrlMlEbmKXkwFgQmh4sRqCHg== X-Google-Smtp-Source: APiQypLA4VpplStPrIKPuTZThOsazYZ35NP0WIuBndYO79Hf3uzgzq/3ckqCDE+mkVVD86+HiFAWdoHL8Nbn6M0Ax2M= X-Received: by 2002:adf:b1c9:: with SMTP id r9mr15433729wra.271.1588840955921; Thu, 07 May 2020 01:42:35 -0700 (PDT) MIME-Version: 1.0 References:

In-Reply-To: Date: Thu, 7 May 2020 10:42:25 +0200 Message-ID: To: Davey Shafik Cc: PHP Internals Content-Type: multipart/alternative; boundary="000000000000c8578f05a50adcad" Subject: Re: [PHP-DEV] [RFC] <> Attribute From: kontakt@beberlei.de (Benjamin Eberlei) --000000000000c8578f05a50adcad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 7, 2020 at 10:27 AM Davey Shafik wrote: > > > On Thu, May 7, 2020 at 01:18 Benjamin Eberlei wrote= : > >> >> >> On Thu, May 7, 2020 at 10:10 AM Davey Shafik wrote: >> >>> >>> >>> On Thu, May 7, 2020 at 00:22 Benjamin Eberlei >>> wrote: >>> >>>> Hi everyone, >>>> >>>> The attributes RFC specifically looked into the use of attributes at t= he >>>> engine/compiler level. >>>> >>>> To have a showcase of this with the 8.0 release I want to propose this >>>> RFC >>>> for a <> attribute: >>>> >>>> https://wiki.php.net/rfc/deprecated_attribute >>>> >>>> <> is the most obvious engine attribute to add at the >>>> beginning >>>> in my opinion, as >>>> >>>> - all other languages with Attributes/Annotations support have it as >>>> well >>>> - its effects are quite obvious to understand, as such offer a good >>>> example >>>> and intro to attributes >>>> - with potential property/class constant deprecation it adds something >>>> that >>>> was not possible in userland before. >>>> >>>> Let me know what you think! >>>> >>>> greetings >>>> Benjamin >>> >>> >>> Hi Benjamin, >>> >>> Two things: >>> >>> 1) as a matter of course, I prefer things that can be done in userland >>> be done in userland unless there is a clear performance or other win. T= his >>> doesn't qualify for me, except that it would be possible to use the sam= e >>> mechanism in core, but that really only gives us the ability to reason >>> around depredations with reflection and I don't see much value in that.= I'm >>> not entirely convinced that a PSR and a defecto implementation isn't a >>> better solution here. This isn't a show-stopper though. >>> >> >> Can you clarify a bit your argument "ability to reason around >> deprecations only with reflection"? >> >> At the moment we can only reason about deprecations by using both >> token_get_all and finding that a method calls trigger_error >> E_USER_DEPRECATED and by looking at the doc comments (via reflection) fo= r >> "@deprecated". My argument for this attribute is that it leads to both a >> documentation based deprecation, and a runtime declaration at the same >> time. It is a better result than what we can do in userland in my opinio= n. >> > > I don't see any valid reason to be checking for deprecations at runtime > with reflection. This attribute has more value when reading the code or > doing static analysis. Neither of which requires that it be implemented i= n > core. Plus, userland gives us the reflection ability *anyway*. > This attribute is "reflected" by the engine during compilation, userland doesn't have to reflect it again itself. on a code level the engine "patches" each function automatically, this would do the following at compile time: @@ -1,6 +1,6 @@ > function foo() { + trigger_error('Function foo() is deprecated', E_USER_DEPRECATED); return 'foo'; } > > >> >> >>> >>> 2) AFAICT you cannot add an attribute to a function argument, and the >>> only way I can see to resolve that is to add a "DeprecatedArgument" >>> attribute applied to the function that takes the name as the first arg = (and >>> the message as the second). Now you're looking at: >>> >>> <> >>> <> >>> function bat($foo =3D null, $bar =3D null) { } >>> >>> It's not great IMO. Having said that, I don't think this bit is really >>> necessary =E2=80=94 unlike the other suggested uses, an argument isn't = an isolated >>> thing, so much as part of the function signature as a whole and removin= g >>> arguments is better done by deprecating the entire function and introdu= cing >>> a new version with a different name. So maybe we just don't need this? >>> >> >> It is possible to add attributes to parameters. This was added as an >> improvement during the Attributes RFC (it was not possible in the first >> draft). >> > > I went back and looked and still missed that, oops! I still stand by my > statement about it being bad practice ;) > Yes you might be right that the parameter deprecation is the one with the "least" value from all of them. > > - Davey > --000000000000c8578f05a50adcad--