Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110058 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 69748 invoked from network); 7 May 2020 09:51:56 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 May 2020 09:51:56 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 57CA91801FD for ; Thu, 7 May 2020 01:27:19 -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.6 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.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 ; Thu, 7 May 2020 01:27:18 -0700 (PDT) Received: by mail-yb1-f181.google.com with SMTP id i16so2489362ybq.9 for ; Thu, 07 May 2020 01:27:18 -0700 (PDT) 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=1rgBOQCJN/7ZTo1Fbus8aQrmp7o6jwmstHWTJxopFXU=; b=LCr58ko0f+GHgEHvTsYqbijDYUuH6vT9owU4loYRhNIFLS/CHiIAmBoSIJlbPtooCj azxHre0m7jMbZZgnmWjaA0Wm0Ce9hPEBLvmgOyM9J60WLxDrsXqfPGY1V/c4CMKXbHsX zJrPtUdSp72dFUChj+WR1Ke1wzzwEA7KQet95XdtFW4jDjb7EtW1QED+ijdC7cZ31bj8 /K81ElGlSilSYZUk44XDPkgxrcY6b15I25LWRx/XP2KXKBxqi2Kk6iawM8peX7q/jKqp Wa+fOZ0Qlp5cdXxwl7gLjB7yssvPz5qPkQKjSvn9EvcxC+gcqTUEjMjtKUafCBPG8hE6 RO7g== X-Gm-Message-State: AGi0Pubqqz8VEAa1I4CPeCoiu3vAMgXHhoOwm/63Ly0sdLgny1Y5BsCH l5bmgG2yEzaQOfb4fhWgleFA4uE6k2y1sFVKd61rsw== X-Google-Smtp-Source: APiQypL8AQcv948TZQ1pBCfiMGLrapLuvPabQ69hy5KMTu2v/nzTaweYx2l8FfySb91rT/hIoBJUrVw3vj3A4Eceojs= X-Received: by 2002:a25:5683:: with SMTP id k125mr20174461ybb.427.1588840038231; Thu, 07 May 2020 01:27:18 -0700 (PDT) MIME-Version: 1.0 References:

In-Reply-To: Date: Thu, 7 May 2020 01:27:07 -0700 Message-ID: To: Benjamin Eberlei Cc: PHP Internals Content-Type: multipart/alternative; boundary="00000000000015870f05a50aa63b" Subject: Re: [PHP-DEV] [RFC] <> Attribute From: davey@php.net (Davey Shafik) --00000000000015870f05a50aa63b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 th= e >>> 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 we= ll >>> - 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 b= e >> done in userland unless there is a clear performance or other win. This >> doesn't qualify for me, except that it would be possible to use the same >> 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 deprecation= s > 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) for > "@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 opinion= . > 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 in core. Plus, userland gives us the reflection ability *anyway*. > > >> >> 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 a= n isolated >> thing, so much as part of the function signature as a whole and removing >> arguments is better done by deprecating the entire function and introduc= ing >> 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 ;) - Davey --00000000000015870f05a50aa63b--