Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111339 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 88615 invoked from network); 5 Aug 2020 13:22:45 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 Aug 2020 13:22:45 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0C0901804C8 for ; Wed, 5 Aug 2020 05:20: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=-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-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) (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 ; Wed, 5 Aug 2020 05:20:37 -0700 (PDT) Received: by mail-wr1-f68.google.com with SMTP id a14so40520331wra.5 for ; Wed, 05 Aug 2020 05:20:37 -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=IE/YYbdK0shBrm1xkf/0V5ofe1irhrqa12tM4ZtNLU8=; b=JUGQ0MUJJB9G+F6+RLEeUai5+Hc4pRlYeJeHEhC6IWY0szylfUdOp92nHZozs7txPO 36r/BAfQKee/FIeSPGkySOUpk5NLjKl1yLvF7+mg5c3Jc7xfWhbRetjNCXTueryjgQUI E4hK6BEPCOCo8ZuktbsLuZ8DcpBTdkjwBS00ApVLqEQC6buU0gwWvBTbkkwTvrX2d1GL +FzVOA1EawS03UJkDlLYsO682ZZHb28DnjRgijw7qd2gLYF3Tf4zFzJgzXSRLslvu0vw CzzbCF0uvdGsbTx5tI1rEgjJsBCj0uGf3T8R+GPvXUtf4SESKtGK86z7EqqdcYhMZ566 gZOw== 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=IE/YYbdK0shBrm1xkf/0V5ofe1irhrqa12tM4ZtNLU8=; b=c3EzxHxUgCQiATDeIGahvofW0er/ZDWQfX7GKFjTt1k9nCgLsnsjXwkPfmShmetrTM 13enopP9hgdLPBMpemx+2t+/CZd1fh+aGimALLtSn0BPdCLHZl454yT3eys0vO1tb/1P Oc2nad376+zTuIhHkSy+U98+9GETHk32vrFDgc3HqIT42ewLyOFYTVt+GeB0MbMr52Rn fz/jMo1UZirzZP225SIWTPbTRghjMV2dLamtv0ERep7gpj/g8TYpUXSBSK6UHTL3iHQN jkiHdMfU+qFyZJWlzS+BOyPK9ihklGUs21tvKsez3TpA6lGQ1otFlRRjrgicY57ZAI3A eyWw== X-Gm-Message-State: AOAM5332VAakHDrc2/NSX4+NrLCBFFHOOshTU0K7koXotmUOtdqk0Q5E GxjciGICY5WMIHTGpHGH6gAwl5IvQNv0SnbUi8/5/w== X-Google-Smtp-Source: ABdhPJwOGJH7Y2PCRYAqa8qVn6Ax46yIcjJLOjOQouE9rdXGUNp9HgPuJvJkwVic9fd1lrBisD5seL2UFmKLBRmvToA= X-Received: by 2002:adf:ce89:: with SMTP id r9mr2778914wrn.116.1596630033260; Wed, 05 Aug 2020 05:20:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 5 Aug 2020 14:20:21 +0200 Message-ID: To: Theodore Brown Cc: Derick Rethans , PHP Developers Mailing List Content-Type: multipart/alternative; boundary="000000000000f87d7a05ac206512" Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2 From: kontakt@beberlei.de (Benjamin Eberlei) --000000000000f87d7a05ac206512 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown wrote: > On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans wrote: > > > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute > > Syntax Change RFC to reflect that process: > > > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > > > Patches and comments welcome. > > Hi Derick, > > I don't agree with the main argument put forward in this RFC: > > > The main concern is that @@ has no ending symbol and it's > > inconsistent with the language that it would be the only > > declaration or statement in the whole language that has no ending > > termination symbol. > > Attributes are not a standalone statement or declaration; they are > metadata *on* a declaration. They cannot stand alone, but always > modify the following declaration, just as public and static modify > a method, or a type declaration modifies a parameter or property. > > Modifying declarations (e.g. for visibility and type) do not have an > ending symbol. For example, we don't write something like: > > [public] function foo([int] $bar) {} > > With the @@ syntax attributes a treated consistently with type and > visibility declarations: > > @@Jit > public function foo(@@Deprecated int $bar) {} > > So there is nothing inconsistent about not having a termination > symbol - this is in harmony with visibility and type declarations in > PHP, as well as the attribute syntax used by a majority of C family > languages. [1] > Attributes are potentially way more complex than a visibility keyword. As such it is a reasonable requirement to say they should have a unified ending symbol, or more broadly speaking that attributes should be enclosed by syntax. It looks nice for a simple attribute like @@Jit, or for a one without arguments like the used @@Deprecated, but as soon as there are more than one, and they each get arguments, enclosing them has its own benefits over them just standing for themselves. > > When it comes to supporting attribute grouping, I actually consider > this a downside of the #[], @[], and <<>> syntaxes. It complicates > the internal implementation, and makes it so developers have to > choose between two different syntaxes when adding more than one > attribute. In real-world use cases the @@ syntax is just as or even > more concise without the extra parser/compiler complexity: > > #[Attr1, Attr2] # 15 chars > > @@Attr1 @@Attr2 # 15 chars > > # 4 lines, 53 chars not counting whitespace > @[ > AttrWithParam("foobar"), > SomeOtherAttr("fizzbuzz"), > ] > > # 2 lines, 52 chars > @@AttrWithParam("foobar") > @@SomeOtherAttr("fizzbuzz") > > I agree that we want the best syntax, not necessarily the best > **looking** syntax. I still believe that the @@ syntax offers the best > balance here. It's familiar, concise without additional complexity, > and doesn't break useful syntax the way @[] and #[] do. > Yes, we have been doing this for 20 years, adding annotations enclosed with /** and */ with each enclosing on its own line for the most part. We even added stars in front of every inbetween line. we are stepping into unchartered territory here with @@ by our standards as PHP community. Using "C familiy" as an argument that they made @ work does not mean much, because the language itself is just the "interface" to the implementation, each C family language probably has vastly different parsers, concerns and approaches. It should be right for PHP. > Kind regards, > Theodore > > [1]: > https://wiki.php.net/rfc/shorter_attribute_syntax#comparison_to_other_languages > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --000000000000f87d7a05ac206512--