Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111620 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 35366 invoked from network); 19 Aug 2020 06:45:10 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 Aug 2020 06:45:10 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E98971804AC for ; Tue, 18 Aug 2020 22:46:29 -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-Virus: No X-Envelope-From: Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) (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 ; Tue, 18 Aug 2020 22:46:28 -0700 (PDT) Received: by mail-wr1-f65.google.com with SMTP id r2so20264286wrs.8 for ; Tue, 18 Aug 2020 22:46:28 -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=M4rPA4iLfjVgBSgmOSEiKy/jOsuBkj6OyvSSdgq/x7w=; b=ZtLa7GdOuhUr7Hy0V0wmPvtn1nxKUjR5x7X6Txv51XL6eVgcKH5hjhXmxSeOaABYR+ C1X0WgE6eLP2sKiFmWyiqjW1LdKG6SngKSZeBcMQ7SdA97/khrvBoXAQhbXoiPiqD9Mo +1vfMzXZgbBbNABgZ7PHylff4Ei5pOM0lpup9y4BYrAoJovdTfV8v9sf+9n09IU8sVzw PGYfoZeUoOigpyrkVzaYaJqj7tSlpiVsknvdFDkWt8ailY1bqQc5eU3YjlAowcG0gaBk m5arDOIeM1HpC6QQedldhzl5zviVg9QKgCs6cmfIWrxfSKOYTUjBWzzw4ep8OEW2Fvfq 2kNQ== 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=M4rPA4iLfjVgBSgmOSEiKy/jOsuBkj6OyvSSdgq/x7w=; b=uTACAIUz0PkjxZAqoEWzW1nE2NNRZeijpD47CWO7/LIMDcZ1en/7f+D0AiDn78SCYI pdhBOXDJ3N7ls5F+Z9WeSfarcVOplE81w8TurpV/l31PEeYZbPHBz+yRuwRVcoL+We8p L8AZ3ojGdqX6KLiKRM79CpETOiA/Uh8w+24CRLR4qlpcsiSMX5ZANqnMuUL/udHXH31Q 6Q0T14DyStKGXlbQVVSXGoKxx6C1NwQdEyfsn1vCAvidSUNHZsz+UFdxAH50zeboHodc 6FfkVMlj/fLSoV8saM24+1NyQD2jLLfM1uX8/+Vos18hwvXtaILUaBdpUAn/3ABQX9io QL4w== X-Gm-Message-State: AOAM533jOI5S7lzjAqCSY4/2JawH93jKUNtzcQieJzKmMnQ3PeMK+dcr Q8RNn4jSH1dB64CxBdwjxyVBOgQoSYDkaekEj0JvYA== X-Google-Smtp-Source: ABdhPJxxQCpKzpj7MrwPBMIGMDws6Drj+cdJCYp79pVtH4Z3aDgm7O9dQqNqZsOA5VTIaDrYP2lWcOh28U57w4PAEvM= X-Received: by 2002:adf:edd0:: with SMTP id v16mr25269925wro.271.1597815987565; Tue, 18 Aug 2020 22:46:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 19 Aug 2020 07:46:15 +0200 Message-ID: To: Theodore Brown Cc: Derick Rethans , PHP Developers Mailing List Content-Type: multipart/alternative; boundary="0000000000005b07a805ad3486fc" Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2 From: kontakt@beberlei.de (Benjamin Eberlei) --0000000000005b07a805ad3486fc Content-Type: text/plain; charset="UTF-8" On Wed, Aug 19, 2020 at 12:03 AM Theodore Brown wrote: > On Tue, Aug 18, 2020 at 1:00 PM Benjamin Eberlei > wrote: > > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > > > I have updated the RFC one last time with as much of the feedback > > as possible: > > > > - a section about comparing to complexity of type definitions > > - removal of the machine reading section as too narrow and > > ultimately not that important as downstream libraries just have to > > deal with any of it > > - some more nuances in forward compatibility pro/cons section of #[] > > - smaller corrections and improvements. > > > > I don't think something major is missing now. > > Hi Benjamin, > > Thanks for the updates. I just have a few more thoughts on aspects > that haven't been mentioned before: > > 1. The **Attributes are not like Modifiers** section makes an > argument that having an end delimiter "groups docblock comment and > attributes into two similarly shaped syntax blocks that prefix the > declaration increasing familiarity." > > In my own (admittedly subjective) opinion, an end delimiter on > attributes actually increases confusion when there is also a > docblock. To reuse the example from the RFC: > > /** > * A comment describing things. > * > * @psalm-suppress SomeRule > */ > #[ > ORM\Entity(), > ORM\Table("baz") > ] > final class Something { > } > > Because the attribute group has its own start and end delimiters, it > almost looks like the doc comment applies to the attribute block > rather than the class. > > With the `@@` or `@:` syntax, it seems clearer that attributes are > part of the class/function/property declaration, rather than their > own standalone construct which docblocks can be applied to: > > /** > * A comment describing things. > * > * @psalm-suppress SomeRule > */ > @@ORM\Entity > @@ORM\Table("baz") > final class Something { > } > > > Given that the only complex part of an attribute is the optional > argument list, which already has its own start/end delimiters, I > ultimately don't find the "complexity" argument very compelling for > needing an additional attribute end delimiter besides. > > > 2. In the **Discussion on grep'ability** section, the RFC says > "Enforcement of same line is also not the case for other > declarations that benefit from grep'ability such as classes, > functions, constants and so on in PHP already, so this is not > consistent within the language." > > This seems to be outdated information, based on Martin's original > patch before the "Treat namespaced names as single token" RFC was > accepted. In the current `@@` implementation, there is no single-line > enforcement, consistent with other parts of the language. > Right, i didn't realize this restriction was lifted and updated this section. This doesn't change the argument though that when you need coding styles to enforce a particular style that grepability works, then you can find a coding standard with all syntaxes that has good grepability, i.e. by not using grouping. > > Not having whitespace between the attribute token and name would be > enforced by coding style conventions, just as is the case with > function/class/constant definitions. > > Note that there is some precedent in PHP for choosing syntax that > ensures easier searching (for example, the decision to place return > type declarations after the parameter list rather than before the > function name). > > Grep'ability isn't a big deal when finding usages in an IDE, but > sometimes there is a need to search code on a server or other source > without an IDE, in which case easy grep'ability can be very helpful. > > Sincerely, > Theodore --0000000000005b07a805ad3486fc--