Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110332 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 63832 invoked from network); 2 Jun 2020 00:06:52 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 2 Jun 2020 00:06:52 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9C7451804D3 for ; Mon, 1 Jun 2020 15:48:36 -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-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 ; Mon, 1 Jun 2020 15:48:35 -0700 (PDT) Received: by mail-wm1-f51.google.com with SMTP id r15so1126501wmh.5 for ; Mon, 01 Jun 2020 15:48:35 -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=DSQTS0Ruu8IchS59VmW0y++IAdvxvva7u54Z/kj4Yv0=; b=YCRKs8GxweR9hhr8ndFBq8fWcaumRL3vyI83L0EqnF+XMFMlMM5N1RhFXHtNfSVFkv NctYPHsB60Ghh+RFvWStMKZhBb2skPz4c/f+hMr4PuoySS52lCwG6W1kD4AJVbP2aT3I 91CbZBGUYmHX7junTuGnM0qVsnsPRr0vm5h9KmwzQ/SZPVQQzg9sgxkyOgfBJonQydXC VVX2I1JA07DD754NH/AvoimloYkvfidqrw+u3toWXCcAzMN08I6wCF4P990K5lvz0PJQ c582Lf7tciO7ddcEiE8vKzD8wpy1aJq4n4PTGzxO+JntV0n4pvIQh3ev/4LbPPXMXbji XPwA== 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=DSQTS0Ruu8IchS59VmW0y++IAdvxvva7u54Z/kj4Yv0=; b=IA2cbCRCA6Rw4zfozE1gWNvFn9WV/RmzrPqNZU5jMTFVzAqw1kCdhqOipgVTFKGeZV 65KIAA4KZnb23MzAIQd03J9+jUZS/ZzOy37elr5YK6Y4JKwPxZMMmYiop8LNrEv2cQfM IipfqhIXaZxIpGTbsJzrR5VIvgauLxMZOKcAwFYOARjzzjxcXzp7/n5XvByauo6Y3Wi2 WX9kiNLycbny3ACufIVqm3f91jjvipDUOprJZhUGWd0dyTEOdDvZHaeYhOVBPFAweFyQ H6lLELenPrC6EUvVdf8wt2EVWDs9ytbljIs1xZ1ZQ8uN/p7x88QdoWTj/F4pKePFN/4V BkXA== X-Gm-Message-State: AOAM531xwxL5dXJ3EvePOK1PuMt2ChXG88YMo7rKAEQz07teyJx7nEi8 +ApwF68kqzf6BATI2V1dPWuK2CL81khYmJJTmkn3XQ== X-Google-Smtp-Source: ABdhPJzq7TWMaABKkHvk2xqfBlftCqXubwtrUt75gshYeZF+kuV73M2QpzJ0QR3QwOlzPIHH8JTgR98ySYDrTTfgyIo= X-Received: by 2002:a1c:810a:: with SMTP id c10mr1302980wmd.107.1591051713300; Mon, 01 Jun 2020 15:48:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 2 Jun 2020 00:48:22 +0200 Message-ID: To: Theodore Brown Cc: PHP Internals Content-Type: multipart/alternative; boundary="00000000000030e06b05a70d981d" Subject: Re: [PHP-DEV] [RFC] Amendments to Attributes From: kontakt@beberlei.de (Benjamin Eberlei) --00000000000030e06b05a70d981d Content-Type: text/plain; charset="UTF-8" On Mon, Jun 1, 2020 at 1:48 AM Theodore Brown wrote: > On Wed, May 20, 2020 at 12:07 PM Benjamin Eberlei > wrote: > > > the Attributes RFC was rather large already, so a few things were left > > open or discussions during the vote have made us rethink a things. > > > > https://wiki.php.net/rfc/attribute_amendments > > > > These points are handled by the Amendments RFC to Attributes: > > > > 1. Proposing to add a grouped syntax < > > Hi Benjamin, > > I find the grouped attribute proposal somewhat troubling. The RFC > contains the following example: > > ```php > < Attr2("bar")>> > public function test() > { > } > ``` > > The problem with this syntax is that adding a new attribute at the > start or end of the list, or removing one of the attributes, will > require modifying multiple lines. For some time the language has been > moving away from this (see the various RFCs to allow trailing commas > in more places), so this feels like a step backwards. > > If trailing commas are allowed in grouped attributes, you could > write it this way instead: > > ```php > << > Attr2("foo"), > Attr2("bar"), > >> > public function test() > { > } > ``` > > But to me this still feels rather clunky. It requires two extra lines, > and when moving from two attributes to one attribute (or vice versa), > you'd still probably end up modifying multiple lines. > I have added trailing commas to the attribute grouping. Now that its possible everywhere, we should go with it here directly from the beginning. About clunkyness, I am not sure this makes sense as an argument, bceause the extra lines are present for all other cases of trailing commas in popular coding styles: [ "arg1", "arg2", ] or foo( "arg1", "arg2", ); > > Another issue with the grouped syntax is that comma separated > attributes can be easy to confuse with comma separated attribute > arguments. For example: > > ```php > <> > <> > function bar() {} > ``` > > It can be hard to tell which line contains multiple attributes vs. > multiple attribute arguments. > The same is true about commas in nested short arrays. > > Ultimately it seems like the grouped attribute proposal is attempting > to work around the poor usability of the current verbose syntax. Maybe > it would be better to instead propose a simpler syntax that avoids > these issues. I know that some internals members expressed interest > in an `@@` token, but this was never voted on. > If you feel strongly about it, please create your own RFC for this. You would need to put it under discussion within this week though, as the feature freeze deadlines are looming. Personally I have no interest in opening up the syntax question again, because there are really not many objective arguments to be made, its mostly subjective and feeling based. > > Having a distinct token for attributes would entirely avoid the issues > of having to modify multiple lines when adding/removing attributes, as > well as confusion with shift operators and comma-separated attribute > arguments. E.g. the RFC example would look like this instead: > @@ is not a distinct token though, because it is already valid syntax to have the error silence operator multiple times after each other. > > ```php > @@Attr2("foo") > @@Attr2("bar") > public function test() > { > } > ``` > > To me this would be a lot cleaner and fit in better with the rest of > the language. > > Best regards, > Theodore > --00000000000030e06b05a70d981d--